Custom Search
|
Date: September 23, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
In-reply-to:
<43329C01.9060602@xxxxxx> (Sven Joachim's message of "Thu, 22 Sep 2005 13:56:49 +0200")
References:
<87irwuub52.fsf@xxxxxxxxxxxxxxxxxxx> <43329C01.9060602@xxxxxx>
Sven Joachim <sven_joachim@xxxxxx> writes: > [...] > Therefore, I think emacsen-common should not ship an init file. New > users can enable Font Lock mode and Transient Mark mode easily enough > via the "Options" menu (assuming they run Emacs under X, which every > newbie should do!). Hmm, yeah, all good points. The other solution would be to change the defaults in Emacs itself but we definitely don't want to go down that road... -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 23, 2005
From: Peter S Galbraith <p.galbraith@xxxxxxxxxxxxxxxx>
In-reply-to:
<87irwtg1iw.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
> <87k6hcupec.fsf@xxxxxxxxxxxxxxxxxxx> <20050920135601.8136810A74A@xxxxxxxxxxxxxxxx> <87br2nvkjd.fsf@xxxxxxxxxxxxxxxxxxx> <20050920152127.483BC10A74A@xxxxxxxxxxxxxxxx> <87vf0vu3sr.fsf@xxxxxxxxxxxxxxxxxxx> <87irwtg1iw.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
Rob Browning <rlb@xxxxxxxxxxxxxxxx> wrote: > I'd like to figure out what needs fixing and fix it, but I want to be > careful because some of the emacsen-common stuff is trickier than I > often think at first glance. > > > I wouldn't have a problem with that, it's your choice. Perhaps there is > > an alternate solution that we haven't thought of yet... > > Let me read this thread more carefully and try to understand the issue > clearly, and I'll see if I have any suggestions. I've decided to populate the Emacs-flavour specific directiories with symlinks to the real .el files: apt-sources.el -> /usr/share/emacs/site-lisp/debian-el/apt-sources.el apt-sources.elc apt-utils.el -> /usr/share/emacs/site-lisp/debian-el/apt-utils.el apt-utils.elc deb-view.el -> /usr/share/emacs/site-lisp/debian-el/deb-view.el deb-view.elc debian-bug.el -> /usr/share/emacs/site-lisp/debian-el/debian-bug.el debian-bug.elc debian-el-loaddefs.el -> /usr/share/emacs/site-lisp/debian-el/debian-el-loaddefs.el debian-el-loaddefs.elc debian-el.el -> /usr/share/emacs/site-lisp/debian-el/debian-el.el debian-el.elc When you think about it, it's the best way to be sure a file you don't want loaded never get loaded. I presume this should be in Emacs policy? Peter
Date: September 22, 2005
From: Peter S Galbraith <psg@xxxxxxxxxx>
In-reply-to:
Message from Rob Browning <rlb@xxxxxxxxxxxxxxxx> of "Wed, 21 Sep 2005 22:03:47 PDT." <877jd9g0cs.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
> <87k6hcupec.fsf@xxxxxxxxxxxxxxxxxxx> <20050920135601.8136810A74A@xxxxxxxxxxxxxxxx> <87br2nvkjd.fsf@xxxxxxxxxxxxxxxxxxx> <20050920152127.483BC10A74A@xxxxxxxxxxxxxxxx> <877jd9g0cs.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
Rob Browning <rlb@xxxxxxxxxxxxxxxx> wrote: > Peter S Galbraith <psg@xxxxxxxxxx> writes: > > > How likely it is that we can get emacsen-common fixed? That package has > > seen a single upload since `oldstable' (woody?) > > Hmm, though there was a long period with no uploads, 1.4.16 was > uploaded in January and should be in testing and sarge. That's the single upload I was talking about. :-) Rob, that's great if you can make more uploads. Perhaps then we won't have to worry so much about breaking things if we know stuff can be quickly fixed. I don't recall why the current adding to load-path scheme had to be worked out, but it certainly seems imperfect to me. We must have the ability to add stuff that we either choose to override Emacs' libraries, or not override them if they exist. That's currently not easy to do. Thanks, Peter
Date: September 22, 2005
From: Sven Joachim <sven_joachim@xxxxxx>
In-reply-to:
<87irwuub52.fsf@xxxxxxxxxxxxxxxxxxx>
References:
<87irwuub52.fsf@xxxxxxxxxxxxxxxxxxx>
Romain Francoise wrote:
What would people think of making emacsen-common provide a default Emacs init file in /etc/skel that would enable Font Lock mode and Transient Mark mode? I think very few new users wouldn't want them, and even if they do they could either remove the default ~/.emacs.el file, or comment out these options. Thoughts?
This is discouraged by the Policy Manual, section 10.7.5, and with good reason: For many (most?) people, their user account is created *before* the installation of emacsen-common, so the init file won't make it to their home directory. If emacsen-common is to provide a default init file, it should probably rather be a system-wide one, i.e. /etc/emacs/default.el. However, that has a serious drawback as well: Users have to put "(setq inhibit-default-init t)" in their .emacs to change anything that's set in default.el. I can imagine the following scenario: The Emacs newbie disables Transient Mark mode via the "Options" menu, saves his options, restarts Emacs -- and wonders why the option apparently wasn't saved (overridden by the default.el, but will he find out that?!). Therefore, I think emacsen-common should not ship an init file. New users can enable Font Lock mode and Transient Mark mode easily enough via the "Options" menu (assuming they run Emacs under X, which every newbie should do!).
Date: September 22, 2005
From: Rob Browning <rlb@xxxxxxxxxxxxxxxx>
In-reply-to:
<20050920152127.483BC10A74A@xxxxxxxxxxxxxxxx> (Peter S. Galbraith's message of "Tue, 20 Sep 2005 11:21:27 -0400")
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
> <87k6hcupec.fsf@xxxxxxxxxxxxxxxxxxx> <20050920135601.8136810A74A@xxxxxxxxxxxxxxxx> <87br2nvkjd.fsf@xxxxxxxxxxxxxxxxxxx> <20050920152127.483BC10A74A@xxxxxxxxxxxxxxxx>
Peter S Galbraith <psg@xxxxxxxxxx> writes: > How likely it is that we can get emacsen-common fixed? That package has > seen a single upload since `oldstable' (woody?) Hmm, though there was a long period with no uploads, 1.4.16 was uploaded in January and should be in testing and sarge. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Date: September 22, 2005
From: Rob Browning <rlb@xxxxxxxxxxxxxxxx>
In-reply-to:
<87vf0vu3sr.fsf@xxxxxxxxxxxxxxxxxxx> (Romain Francoise's message of "Tue, 20 Sep 2005 18:01:08 +0200")
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
> <87k6hcupec.fsf@xxxxxxxxxxxxxxxxxxx> <20050920135601.8136810A74A@xxxxxxxxxxxxxxxx> <87br2nvkjd.fsf@xxxxxxxxxxxxxxxxxxx> <20050920152127.483BC10A74A@xxxxxxxxxxxxxxxx> <87vf0vu3sr.fsf@xxxxxxxxxxxxxxxxxxx>
Romain Francoise <rfrancoise@xxxxxxxxxx> writes: > I don't know, Rob appears to be active but the package has certainly > seen less attention than it deserves. It should be about to see substantially more. I'd like to figure out what needs fixing and fix it, but I want to be careful because some of the emacsen-common stuff is trickier than I often think at first glance. > I wouldn't have a problem with that, it's your choice. Perhaps there is > an alternate solution that we haven't thought of yet... Let me read this thread more carefully and try to understand the issue clearly, and I'll see if I have any suggestions. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Date: September 21, 2005
From: Peter S Galbraith <p.galbraith@xxxxxxxxxxxxxxxx>
In-reply-to:
<87irwuub52.fsf@xxxxxxxxxxxxxxxxxxx>
References:
<87irwuub52.fsf@xxxxxxxxxxxxxxxxxxx>
Whatever you do, some people are going to complain. :-( -- Peter S Galbraith <p.galbraith@xxxxxxxxxxxxxxxx>
Date: September 21, 2005
From: Peter S Galbraith <psg@xxxxxxxxxx>
Anyone want to maintain the gnus-bonus-el package? I'm officially maintaining the `gnus-bonus-el' package because I inherited it with emacs-goodies-el a long time ago. But I don't use gnus and it's nearly impossible for me to sort out the bugs. Description: Miscellaneous add-ons for Gnus This package contains a few Emacs-Lisp files, obtained from various sources, including the gnu.emacs.sources newsgroup and a few websites, that provide various functions to Gnus, the Emacs mail and news reader. . This package contains: gnus-eyecandy - enhance the group buffer by adding icons. gnus-filterhist - add a buffer which display the message filtering gnus-junk - semi-automatic replies to junk e-mails; gnus-pers - an alternative to gnus-posting-styles. message-x - customizable completion in message headers; nnir - searchable mail backend; nnnil - empty, read-only backend; nntodo - manage to-do items; spam-stat - spam-detector based on statistics. Anyone want to maintain it? They could either take it over completely and separately into their own source package, or I could simply add their name to the Alioth project: https://alioth.debian.org/projects/pkg-goodies-el/ where they could commit changes and let me worry about releases. To be honest, I once coaxed Jérôme Marant into doing this, but he doesn't really have time for this so I would let him off the hook. An alternative for me is to simply abandon gnus-bonus-el and purge it from the emacs-goodies-el package. Thanks, -- Peter Galbraith
Date: September 21, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
What would people think of making emacsen-common provide a default Emacs init file in /etc/skel that would enable Font Lock mode and Transient Mark mode? I think very few new users wouldn't want them, and even if they do they could either remove the default ~/.emacs.el file, or comment out these options. Thoughts? -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 20, 2005
From: Kevin Ryde <user42@xxxxxxxxxx>
In-reply-to:
<18278.1127178657@mixed
> (Peter S. Galbraith's message of "Mon, 19 Sep 2005 21:10:57 -0400")
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
>
Peter S Galbraith <psg@xxxxxxxxxx> writes: > > I still add the directory /usr/share/emacs/site-lisp/emacs-goodies-el > at the end of the load-path. I like that because it makes `find-func' work (cf bug 157123). > We need to be able to add to the load-path without shadowing files that > may or may not be present (i.e. present in emacs-snapshot but not in > emacs21). Maybe put both .el and .elc in the specific directories like /usr/share/emacs21/site-lisp when it should apply only to certain flavours. (Ie. not in /usr/share/emacs/site-lisp.) Some tricky postinst could figure out the newness of each flavour to decide whether there's wanted or unwanted shadowing, but initially just manually assign to the right flavour(s).
Date: September 20, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
In-reply-to:
<20050920152127.483BC10A74A@xxxxxxxxxxxxxxxx> (Peter S. Galbraith's message of "Tue, 20 Sep 2005 11:21:27 -0400")
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
> <87k6hcupec.fsf@xxxxxxxxxxxxxxxxxxx> <20050920135601.8136810A74A@xxxxxxxxxxxxxxxx> <87br2nvkjd.fsf@xxxxxxxxxxxxxxxxxxx> <20050920152127.483BC10A74A@xxxxxxxxxxxxxxxx>
Peter S Galbraith <psg@xxxxxxxxxx> writes: > Well, I'm sure that was done for a valid reason. Yep, but it's hard to tell which... > If I have to resort to the symlink solution, everybody who gets this > problem will have to do the same thing. If emacsen-common gets fixed, > it's fixed for everybody! > How likely it is that we can get emacsen-common fixed? That package has > seen a single upload since `oldstable' (woody?) I don't know, Rob appears to be active but the package has certainly seen less attention than it deserves. Perhaps Rob would be willing to hand off maintenance of this package to a team of Emacs people in Debian if we ask. > I'd rather REMOVE /usr/share/emacs/site-lisp/emacs-goodies-el from the > load-path altogether, except that breaks the ability to jump to the code > when viewing variables and functions via `C-h v' and `C-h f'. Much > easier and cleaner than maintaining a collection of symlinks... I wouldn't have a problem with that, it's your choice. Perhaps there is an alternate solution that we haven't thought of yet... -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 20, 2005
From: Peter S Galbraith <psg@xxxxxxxxxx>
In-reply-to:
Message from Romain Francoise <rfrancoise@xxxxxxxxxx> of "Tue, 20 Sep 2005 17:14:14 +0200." <87br2nvkjd.fsf@xxxxxxxxxxxxxxxxxxx>
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
> <87k6hcupec.fsf@xxxxxxxxxxxxxxxxxxx> <20050920135601.8136810A74A@xxxxxxxxxxxxxxxx> <87br2nvkjd.fsf@xxxxxxxxxxxxxxxxxxx>
Romain Francoise <rfrancoise@xxxxxxxxxx> wrote: > Peter Galbraith <GalbraithP@xxxxxxxxxxxxx> writes: > > > 1- Perhaps if I don't explicitely add > > /usr/share/emacs/site-lisp/emacs-goodies-el/ to the load-path, it > > will get added automatically at the tail end, because it is a > > subdirectory of /usr/share/emacs/site-lisp ? > > Nope, it won't be added automatically. Okay, thanks. > > 2- Perhaps emacs-snapshot can be modified to have it's generic load-path > > all done by the time the /etc/emacs startup files are run. That > > way. add entries at the tail end of the load-path would indeed yield > > the expected result. For everybody. Not just me. > > Its load-path is already 'all done' by the time the Debian startup > scripts run, or things would break in horrible ways. > > Your problem is that this code from debian-startup.el (in the > `debian-run-directories' function) stores the original load-path before > running the scripts and then explicitly overwrites load-path, adding any > items added by the Debian startup scripts at the head of the original > load-path: > > ,---- > | ;; restore the old load-path -- including any new paths added by > | ;; files loaded in directory traversal. > | (let ((add-on-package-paths > | (delq nil (mapcar > | (lambda (item) > | (if (not (member item new-path)) > | item > | nil)) > | load-path)))) > | (setq load-path (append add-on-package-paths old-load-path)))))) > `---- Well, I'm sure that was done for a valid reason. But isn't it horribly broken? It means we can't do what's best for the load-path. > This is why your site-lisp directory added at the end of the load-path > in emacs-goodies-el's startup script ends up being moved before the > system load path items after `debian-startup' returns. > > So, we could try to fix emacsen-common by changing this code, or we > could try my (admittedly cumbersome) symlink solution... If I have to resort to the symlink solution, everybody who gets this problem will have to do the same thing. If emacsen-common gets fixed, it's fixed for everybody! How likely it is that we can get emacsen-common fixed? That package has seen a single upload since `oldstable' (woody?) I'd rather REMOVE /usr/share/emacs/site-lisp/emacs-goodies-el from the load-path altogether, except that breaks the ability to jump to the code when viewing variables and functions via `C-h v' and `C-h f'. Much easier and cleaner than maintaining a collection of symlinks... Peter
Date: September 20, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
In-reply-to:
<20050920135601.8136810A74A@xxxxxxxxxxxxxxxx> (Peter Galbraith's message of "Tue, 20 Sep 2005 09:56:01 -0400")
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
> <87k6hcupec.fsf@xxxxxxxxxxxxxxxxxxx> <20050920135601.8136810A74A@xxxxxxxxxxxxxxxx>
Peter Galbraith <GalbraithP@xxxxxxxxxxxxx> writes: > 1- Perhaps if I don't explicitely add > /usr/share/emacs/site-lisp/emacs-goodies-el/ to the load-path, it > will get added automatically at the tail end, because it is a > subdirectory of /usr/share/emacs/site-lisp ? Nope, it won't be added automatically. > 2- Perhaps emacs-snapshot can be modified to have it's generic load-path > all done by the time the /etc/emacs startup files are run. That > way. add entries at the tail end of the load-path would indeed yield > the expected result. For everybody. Not just me. Its load-path is already 'all done' by the time the Debian startup scripts run, or things would break in horrible ways. Your problem is that this code from debian-startup.el (in the `debian-run-directories' function) stores the original load-path before running the scripts and then explicitly overwrites load-path, adding any items added by the Debian startup scripts at the head of the original load-path: ,---- | ;; restore the old load-path -- including any new paths added by | ;; files loaded in directory traversal. | (let ((add-on-package-paths | (delq nil (mapcar | (lambda (item) | (if (not (member item new-path)) | item | nil)) | load-path)))) | (setq load-path (append add-on-package-paths old-load-path)))))) `---- This is why your site-lisp directory added at the end of the load-path in emacs-goodies-el's startup script ends up being moved before the system load path items after `debian-startup' returns. So, we could try to fix emacsen-common by changing this code, or we could try my (admittedly cumbersome) symlink solution... Cheers, -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 20, 2005
From: Peter Galbraith <GalbraithP@xxxxxxxxxxxxx>
In-reply-to:
Message from Romain Francoise <rfrancoise@xxxxxxxxxx> of "Tue, 20 Sep 2005 10:14:35 +0200." <87k6hcupec.fsf@xxxxxxxxxxxxxxxxxxx>
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
> <87k6hcupec.fsf@xxxxxxxxxxxxxxxxxxx>
Romain Francoise <rfrancoise@xxxxxxxxxx> wrote: > Peter S Galbraith <psg@xxxxxxxxxx> writes: > > > Anyone have any bright ideas? > > Create /usr/share/emacs/site-lisp/emacs-goodies-el/<flavor>/ > directories, populate them with symlinks to only the files we want for > each flavor, and add that to the load-path instead. > > It isn't pretty, but it should work... True, but cumbersome. Two things come to mind: 1- Perhaps if I don't explicitely add /usr/share/emacs/site-lisp/emacs-goodies-el/ to the load-path, it will get added automatically at the tail end, because it is a subdirectory of /usr/share/emacs/site-lisp ? (I haven't tried this on emacs-snapshot since I'm not at home right now) 2- Perhaps emacs-snapshot can be modified to have it's generic load-path all done by the time the /etc/emacs startup files are run. That way. add entries at the tail end of the load-path would indeed yield the expected result. For everybody. Not just me. Thanks, Peter
Date: September 20, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
In-reply-to:
<18278.1127178657@mixed
> (Peter S. Galbraith's message of "Mon, 19 Sep 2005 21:10:57 -0400")
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx> <18278.1127178657@mixed
>
Peter S Galbraith <psg@xxxxxxxxxx> writes: > Anyone have any bright ideas? Create /usr/share/emacs/site-lisp/emacs-goodies-el/<flavor>/ directories, populate them with symlinks to only the files we want for each flavor, and add that to the load-path instead. It isn't pretty, but it should work... -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 20, 2005
From: Peter S Galbraith <psg@xxxxxxxxxx>
In-reply-to:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx>
References:
<87wtldvve6.fsf@xxxxxxxxxxxxxxxxxxx>
Romain Francoise <rfrancoise@xxxxxxxxxx> wrote: > The emacs-goodies-el and gnus-bonus-el packages shadow a number of > packages included in emacs-snapshot. This is problematic because some > of these packages are maintained in Emacs CVS and are newer in > emacs-snapshot than in emacs-goodies-el, or may contain changes that are > needed for Emacs 22. > > This is particularly aggravating for ibuffer since the version in > emacs-goodies-el is almost *three years* older than the version in > Emacs. > > Affected packages: > > * emacs-goodies-el: > - wdired.el > - ibuffer.el > - table.el > - newsticker.el > * gnus-bonus-el: > - nnnil.el > - spam-stat.el There's a problem... Even if I skip byte-compilation of these files for emacs-snapshot, I still add the directory /usr/share/emacs/site-lisp/emacs-goodies-el at the end of the load-path. But this is done too soon during startup and this directory ends up shadowing the emacs-snapshot file /usr/share/emacs/22.0.50/lisp/net/newsticker.elc We need to be able to add to the load-path without shadowing files that may or may not be present (i.e. present in emacs-snapshot but not in emacs21). Anyone have any bright ideas? Peter
Date: September 16, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
I'm waiting for a Calendar/Diary fix from Stefan for a minor but annoying bug so this week's snapshot will have to wait a bit. There are no urgent fixes pending. -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 16, 2005
From: Henrik Andersson <h.andersson@xxxxxxxxxxxx>
In-reply-to:
<87k6hh1l1q.fsf@xxxxxxxxxxxxxxxxxxx>
References:
<dgbs5s$m35$1@xxxxxxxxxxxxx> <87r7bq2y4m.fsf@xxxxxxxxxxxxxxxxxxx> <dgdubc$kfh$1@xxxxxxxxxxxxx> <87k6hh1l1q.fsf@xxxxxxxxxxxxxxxxxxx>
Romain Francoise wrote:
Henrik Andersson <h.andersson@xxxxxxxxxxxx> writes:Here you go, I hope you can decipher it...For some reason, `directory-free-space-program' must be set to "df2" in your setup... Could you try to find out why? It could be an init file or a Debian package (since things obviously work for everyone else).In the interim,(setq directory-free-space-program "df") should fix the problem.
Whoops, I guess my memory is not that good after all. I customed this variable on my windows machine, since 'df' there refer to the Digital Fortran compiler and not free disk space. And then used the same .emacs on the debian machine.
So, nothing at all to complain about emacs-snapshot! Thanks! --------------------------------------------- Henrik Andersson Netherlands Institute of Ecology - Centre for Estuarine and Marine Ecology P.O. Box 140 4400 AC Yerseke Phone: +31 113 577473 h.andersson@xxxxxxxxxxxx http://www.nioo.knaw.nl/ppages/handersson
Date: September 16, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
References:
<dgbs5s$m35$1@xxxxxxxxxxxxx> <87r7bq2y4m.fsf@xxxxxxxxxxxxxxxxxxx> <dgdubc$kfh$1@xxxxxxxxxxxxx>
Henrik Andersson <h.andersson@xxxxxxxxxxxx> writes: > Here you go, I hope you can decipher it... For some reason, `directory-free-space-program' must be set to "df2" in your setup... Could you try to find out why? It could be an init file or a Debian package (since things obviously work for everyone else). In the interim, (setq directory-free-space-program "df") should fix the problem. -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 16, 2005
From: Henrik Andersson <h.andersson@xxxxxxxxxxxx>
In-reply-to:
<87r7bq2y4m.fsf@xxxxxxxxxxxxxxxxxxx>
References:
<dgbs5s$m35$1@xxxxxxxxxxxxx> <87r7bq2y4m.fsf@xxxxxxxxxxxxxxxxxxx>
Romain Francoise wrote:
Henrik Andersson <h.andersson@xxxxxxxxxxxx> writes:Searching for program: no such file or directory df2What am I missing?df2? ;-) Retry after doing M-x toggle-debug-on-error RET and post the backtrace. It's probably one of your site-lisp packages messing with Emacs...
Here you go, I hope you can decipher it... ----------------------------------------------------------------------Debugger entered--Lisp error: (file-error "Searching for program" "no such file or directory" "df2")
call-process("df2" nil t nil "-Pk" ".")
get-free-disk-space(".")
insert-directory("/home/henrik/documents/AMK/all_gof/" "--dired -al"
nil t)
dired-insert-directory("/home/henrik/documents/AMK/all_gof/" "-al"
nil nil t)
dired-readin-insert()
dired-readin()
dired-internal-noselect("~/documents/AMK/all_gof/" nil)
dired-noselect("~/documents/AMK/all_gof/")
run-hook-with-args-until-success(dired-noselect
"~/documents/AMK/all_gof/")
find-file-noselect("~/documents/AMK/all_gof/" nil nil t)
find-file("~/documents/AMK/all_gof/" t)
call-interactively(find-file)
Date: September 15, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
References:
<dgbs5s$m35$1@xxxxxxxxxxxxx>
Henrik Andersson <h.andersson@xxxxxxxxxxxx> writes: > Searching for program: no such file or directory df2 > What am I missing? df2? ;-) Retry after doing M-x toggle-debug-on-error RET and post the backtrace. It's probably one of your site-lisp packages messing with Emacs... -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 15, 2005
From: Henrik Andersson <h.andersson@xxxxxxxxxxxx>
Searching for program: no such file or directory df2 What am I missing? --------------------------------------------- Henrik Andersson Netherlands Institute of Ecology - Centre for Estuarine and Marine Ecology P.O. Box 140 4400 AC Yerseke Phone: +31 113 577473 h.andersson@xxxxxxxxxxxx http://www.nioo.knaw.nl/ppages/handersson
Date: September 11, 2005
From: Emilio Lopes <eclig@xxxxxxx>
References:
<87k6hsieht.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Miles Bader writes: > For those of you who were using my arch archive, > miles@xxxxxxxxxxxxxxxxx to track Emacs sources: > My previous publicly available mirror (at push.sourcecontrol.net) > has been stale for quite some time, due to hardware failures. Yes, that incident motivated me to setup my own "dual" Emacs source code repository, first using CVS + GNU Arch (tla) and later using CVS + Darcs. It has be working very well for quite some time now. I described the setup in http://darcs.net/DarcsWiki/InteroperabilityWithCvs Darcs is a free revision control system, released under the GPL and available from http://darcs.net.
Date: September 09, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
References:
<87k6hsieht.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <87d5niwd7k.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Manoj Srivastava <srivasta@xxxxxxxxxx (va, manoj)> writes: > Romain, How about adding these to debian/rules? > ---------------------------------------------------------------------- > confflags += --with-xpm > confflags += --with-jpeg > confflags += --with-tiff > confflags += --with-png > ---------------------------------------------------------------------- We don't need these, they're picked up automatically by the configure script via Build-Depends. (And adding them won't make the build fail if the development files aren't installed, if that's why you're making this suggestion.) > We already have "confflags += --with-gif" (may need to adjust > build-depends, of course) I'll remove that, it's an artefact of previous Emacs 21 versions struggling with libungif support; it's not called for in emacs-snapshot. Thanks for pointing it out. > The branch builds fine from source, but I ran into no end of problems > while trying to use the debian emacs-snapshot branch with yours [...] I'm not sure which branch you're referring to... emacs--miles, perhaps? -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 09, 2005
From: Manoj Srivastava <srivasta@xxxxxxxxxx (va, manoj)>
In-reply-to:
<87k6hsieht.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> (Miles Bader's message of "Thu, 08 Sep 2005 09:34:38 +0900")
References:
<87k6hsieht.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Hi,
Miles, thanks for the branch.
Romain, How about adding these to debian/rules?
----------------------------------------------------------------------
confflags += --with-xpm
confflags += --with-jpeg
confflags += --with-tiff
confflags += --with-png
----------------------------------------------------------------------
We already have "confflags += --with-gif" (may need to adjust
build-depends, of course)
The branch builds fine from source, but I ran into no end of
problems while trying to use the debian emacs-snapshot branch with
yours -- firstly, since src/xfns.c fails to build with gcc 4.01 in
Sid, since src/frame.h defines Qdisplay as an extern Lisp_Object, but
xfns.c defines it as a static Lisp_Object (on line 5286 or so), and
gcc barfs on it now. Either Qdisplay is meant to be a shared resource
(hence the extrern) or purely a local one (hence the static); I made
it a shared resource by removing the static qualifier, but it should
be checked by someone.
But the show stopper is:
,----[ Lisp nesting exceeds `max-lisp-eval-depth' ]
| for el in \
| /usr/local/src/arch/others/tmp/build/lisp/emacs-lisp/byte-opt.el \
| /usr/local/src/arch/others/tmp/build/lisp/emacs-lisp/bytecomp.el \
| /usr/local/src/arch/others/tmp/build/lisp/subr.el \
| /usr/local/src/arch/others/tmp/build/lisp/progmodes/cc-mode.el \
| /usr/local/src/arch/others/tmp/build/lisp/progmodes/cc-vars.el $els; \
| do \
| if test -f $el; \
| then \
| echo Compiling $el; \
| EMACSLOADPATH=/usr/local/src/arch/others/tmp/build/lisp \
| ../src/bootstrap-emacs -batch --no-site-file --multibyte -f \
| batch-byte-compile-if-not-done $el || exit 1; \
| fi \
| done
| Compiling /usr/local/src/arch/others/tmp/build/lisp/emacs-lisp/byte-opt.el
| >>Error occurred processing
| /usr/local/src/arch/others/tmp/build/lisp/emacs-lisp/byte-opt.el:
| error (("Lisp nesting exceeds `max-lisp-eval-depth'"))
| make[2]: *** [compile] Error 1
| make[2]: Leaving directory `/usr/local/src/arch/others/tmp/build/lisp'
| make[1]: *** [bootstrap-build] Error 2
| make[1]: Leaving directory `/usr/local/src/arch/others/tmp/build'
| make: *** [build-stamp] Error 2
`----
I even tried gross hacks like
find lisp -type f -name \*.el | while read el; do emacs -batch \
--no-site-file --multibyte -f batch-byte-compile-if-not-done $$el;\
done
in the rules file, but always there was something else that would
fail.
Am I missing something simple?
manoj
--
I think we're in trouble. Han Solo
Manoj Srivastava <srivasta@xxxxxxxxxx> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Date: September 08, 2005
From: Miles Bader <snogglethorpe@xxxxxxxxx>
In-reply-to:
<87k6hsieht.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<87k6hsieht.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
I wrote: > I just got two new mirrors, which are being properly updated: > (1) http://mirrors.sourcecontrol.net/miles@xxxxxxxxxxxxxxxxx > (2) http://arch.orebokech.com/miles@xxxxxxxxxxxxxxxxx ... > Thanks to Romain Francoise for providing the arch.orebokech.com mirror, and > thanks to Tollef Fog Heen for telling about the mirrors.sourcecontrol.net > "push service" and helping me to get it working. Also thanks to James Blackwell (and I gather, canonical.com these days) for the sourcecontrol.net mirror services, past and present, and for providing a helping hand. -miles -- Do not taunt Happy Fun Ball.
Date: September 08, 2005
From: Miles Bader <miles@xxxxxxx>
For those of you who were using my arch archive, miles@xxxxxxxxxxxxxxxxx to track Emacs sources: My previous publicly available mirror (at push.sourcecontrol.net) has been stale for quite some time, due to hardware failures. I just got two new mirrors, which are being properly updated: (1) http://mirrors.sourcecontrol.net/miles@xxxxxxxxxxxxxxxxx (2) http://arch.orebokech.com/miles@xxxxxxxxxxxxxxxxx [ (1) was previously available, but was out of date, as it used to mirror the old stale archive; now it should be updated properly. ] Thanks to Romain Francoise for providing the arch.orebokech.com mirror, and thanks to Tollef Fog Heen for telling about the mirrors.sourcecontrol.net "push service" and helping me to get it working. -miles -- "Nah, there's no bigger atheist than me. Well, I take that back. I'm a cancer screening away from going agnostic and a biopsy away from full-fledged Christian." [Adam Carolla]
Date: September 06, 2005
From: Miles Bader <snogglethorpe@xxxxxxxxx>
In-reply-to:
<20050906120725.GA13673@xxxxxxxxxxxxxx>
References:
<873bosxpas.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <871x494wk6.fsf@xxxxxxxxxxxx> <buo64tljoc4.fsf@xxxxxxxxxxxxxxxxxxxxxx> <87k6hwxy4i.fsf@xxxxxxxxxxxx> <fc339e4a0509041600303ef89d@xxxxxxxxxxxxxx> <20050904232621.GA1581@xxxxxxxxxxxxxx> <87fyskxfwa.fsf@xxxxxxxxxxxx> <buou0h0kr8f.fsf@xxxxxxxxxxxxxxxxxxxxxx> <buofysjhrlk.fsf@xxxxxxxxxxxxxxxxxxxxxx> <20050906120725.GA13673@xxxxxxxxxxxxxx>
2005/9/6, James Blackwell <jblack@xxxxxxxxxxxxxx>: > > Ok, following that advice, I successfully mirrored my arch repo to my > > sftp account on mirrors.sourcecontrol.net... > > > > The final question is: where does my now-updated mirror show up in > > http-space? > > The old ones are in the way. If you give me a list of the ones that yo're > pusing now, I'll move the old ones out and the new ones will get > remirrored. Hi, I'm just pushing "miles@xxxxxxxxxxxxxxxxx". [So is mirrors.sourcecontrol.net different from push.sourcecontrol.net...?] Thanks, -miles -- Do not taunt Happy Fun Ball.
Date: September 06, 2005
From: jblack@xxxxxxxxxxxxxx (James Blackwell)
In-reply-to:
<buofysjhrlk.fsf@xxxxxxxxxxxxxxxxxxxxxx>
References:
<873bosxpas.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <buo7je4w6in.fsf@xxxxxxxxxxxxxxxxxxxxxx> <871x494wk6.fsf@xxxxxxxxxxxx> <buo64tljoc4.fsf@xxxxxxxxxxxxxxxxxxxxxx> <87k6hwxy4i.fsf@xxxxxxxxxxxx> <fc339e4a0509041600303ef89d@xxxxxxxxxxxxxx> <20050904232621.GA1581@xxxxxxxxxxxxxx> <87fyskxfwa.fsf@xxxxxxxxxxxx> <buou0h0kr8f.fsf@xxxxxxxxxxxxxxxxxxxxxx> <buofysjhrlk.fsf@xxxxxxxxxxxxxxxxxxxxxx>
On Tue, Sep 06, 2005 at 11:12:23AM +0900, Miles Bader wrote: > Miles Bader <miles.bader@xxxxxxxxx> writes: > >> in your ~/.ssh/config > > > > k, let me try that... > > Ok, following that advice, I successfully mirrored my arch repo to my > sftp account on mirrors.sourcecontrol.net... > > The final question is: where does my now-updated mirror show up in > http-space? The old ones are in the way. If you give me a list of the ones that yo're pusing now, I'll move the old ones out and the new ones will get remirrored. Regards, James > > If I look at http://mirrors.sourcecontrol.net/miles@xxxxxxxxxxxxxxxxx, > that's still the old out-of-date mirror... > > Thanks, > > -Miles > -- > `Cars give people wonderful freedom and increase their opportunities. > But they also destroy the environment, to an extent so drastic that > they kill all social life' (from _A Pattern Language_) -- James Blackwell | Life is made of the stuff that hasn't killed Tell someone a joke! | you yet. - yours truly ---------------------------------------------------------------------- GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D 247A 8A55 DA73 0635 7400
Date: September 06, 2005
From: Miles Bader <miles.bader@xxxxxxxxx>
In-reply-to:
<buou0h0kr8f.fsf@xxxxxxxxxxxxxxxxxxxxxx> (Miles Bader's message of "Mon, 05 Sep 2005 14:39:44 +0900")
References:
<m2fyt216tk.fsf@xxxxxxxxxxxxxx> <1124721951.4309e51f428d0@xxxxxxxxxxxxxx> <873bosxpas.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <buo7je4w6in.fsf@xxxxxxxxxxxxxxxxxxxxxx> <871x494wk6.fsf@xxxxxxxxxxxx> <buo64tljoc4.fsf@xxxxxxxxxxxxxxxxxxxxxx> <87k6hwxy4i.fsf@xxxxxxxxxxxx> <fc339e4a0509041600303ef89d@xxxxxxxxxxxxxx> <20050904232621.GA1581@xxxxxxxxxxxxxx> <87fyskxfwa.fsf@xxxxxxxxxxxx> <buou0h0kr8f.fsf@xxxxxxxxxxxxxxxxxxxxxx>
Miles Bader <miles.bader@xxxxxxxxx> writes: >> in your ~/.ssh/config > > k, let me try that... Ok, following that advice, I successfully mirrored my arch repo to my sftp account on mirrors.sourcecontrol.net... The final question is: where does my now-updated mirror show up in http-space? If I look at http://mirrors.sourcecontrol.net/miles@xxxxxxxxxxxxxxxxx, that's still the old out-of-date mirror... Thanks, -Miles -- `Cars give people wonderful freedom and increase their opportunities. But they also destroy the environment, to an extent so drastic that they kill all social life' (from _A Pattern Language_)
Date: September 05, 2005
From: Miles Bader <miles.bader@xxxxxxxxx>
In-reply-to:
<87fyskxfwa.fsf@xxxxxxxxxxxx> (Tollef Fog Heen's message of "Mon, 05 Sep 2005 07:06:13 +0200")
References:
<m2fyt216tk.fsf@xxxxxxxxxxxxxx> <1124721951.4309e51f428d0@xxxxxxxxxxxxxx> <873bosxpas.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <buo7je4w6in.fsf@xxxxxxxxxxxxxxxxxxxxxx> <871x494wk6.fsf@xxxxxxxxxxxx> <buo64tljoc4.fsf@xxxxxxxxxxxxxxxxxxxxxx> <87k6hwxy4i.fsf@xxxxxxxxxxxx> <fc339e4a0509041600303ef89d@xxxxxxxxxxxxxx> <20050904232621.GA1581@xxxxxxxxxxxxxx> <87fyskxfwa.fsf@xxxxxxxxxxxx>
Tollef Fog Heen <tfheen@xxxxxxxxxx> writes: > or just have something like: > > Host mirrors.sourcecontrol.net > Hostname mirrors.sourcecontrol.net > User miles@xxxxxxxxxxxxxxxxxx > > in your ~/.ssh/config k, let me try that... Thanks, -miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research
Date: September 05, 2005
From: Tollef Fog Heen <tfheen@xxxxxxxxxx>
In-reply-to:
<20050904232621.GA1581@xxxxxxxxxxxxxx> (James Blackwell's message of "Sun, 4 Sep 2005 19:26:21 -0400")
References:
<m2fyt216tk.fsf@xxxxxxxxxxxxxx> <1124721951.4309e51f428d0@xxxxxxxxxxxxxx> <873bosxpas.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <buo7je4w6in.fsf@xxxxxxxxxxxxxxxxxxxxxx> <871x494wk6.fsf@xxxxxxxxxxxx> <buo64tljoc4.fsf@xxxxxxxxxxxxxxxxxxxxxx> <87k6hwxy4i.fsf@xxxxxxxxxxxx> <fc339e4a0509041600303ef89d@xxxxxxxxxxxxxx> <20050904232621.GA1581@xxxxxxxxxxxxxx>
* (James Blackwell) | Unless its been fixed, tla can't handle name@host@host. You could either | use Bazaar, or try the compatibility option for old bazaar & tla. That | replaces the first @ with a _ | | Try using | miles_gnu.org--gnu--2005@xxxxxxxxxxxxxxxxxxxxxxxxx/miles@xxxxxxxxxxxxxxxxx or just have something like: Host mirrors.sourcecontrol.net Hostname mirrors.sourcecontrol.net User miles@xxxxxxxxxxxxxxxxxx in your ~/.ssh/config and then just using tla make-archive --mirror miles@xxxxxxxxxxxxxxxxx miles@xxxxxxxxxxxxxxxxxxxxxxxx sftp://mirrors.sourcecontrol.net/miles@xxxxxxxxxxxxxxxxx should work. -- Tollef Fog Heen ,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Date: September 04, 2005
From: jblack@xxxxxxxxxxxxxx (James Blackwell)
In-reply-to:
<fc339e4a0509041600303ef89d@xxxxxxxxxxxxxx>
References:
<m2fyt216tk.fsf@xxxxxxxxxxxxxx> <1124721951.4309e51f428d0@xxxxxxxxxxxxxx> <873bosxpas.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <buo7je4w6in.fsf@xxxxxxxxxxxxxxxxxxxxxx> <871x494wk6.fsf@xxxxxxxxxxxx> <buo64tljoc4.fsf@xxxxxxxxxxxxxxxxxxxxxx> <87k6hwxy4i.fsf@xxxxxxxxxxxx> <fc339e4a0509041600303ef89d@xxxxxxxxxxxxxx>
On Mon, Sep 05, 2005 at 08:00:22AM +0900, Miles Bader wrote: > 2005/9/5, Tollef Fog Heen <tfheen@xxxxxx>: > > * Miles Bader > > > > | Tollef Fog Heen <tfheen@xxxxxx> writes: > > | > http://www.sourcecontrol.net/?action=pushaccount > > | > > > | > It requires you to jump through a few hoops to set up, but it works > > | > fine (I just went through the procedure and tested it). > > | > > | Hmmm, thanks for the pointer. > > | > > | I couldn't get it to work though -- after creating a launchpad account > > | and registering my ssh/gpg keys: > > | > > | $ tla make-archive --mirror miles@xxxxxxxxxxxxxxxxx > > miles@xxxxxxxxxxxxxxxxxxxxxxxx > > sftp://miles@xxxxxxxxxxxxxxxxx@mirrors.sourcecontrol.net/miles@xxxxxxxxxxxxxxxxx > > | Permission denied (publickey). > > | Error reading from server > > > > I think you need to add you SSH key in launchpad as well; that part > > seems to be missing from the instructions. > > Actually I did add my ssh key (and also gpg keys), and indeed that's > enough so that I can use the sftp program to connect to the server and > create and delete files manually; it's just that "tla archive-mirror" > doesn't work. Unless its been fixed, tla can't handle name@host@host. You could either use Bazaar, or try the compatibility option for old bazaar & tla. That replaces the first @ with a _ Try using miles_gnu.org--gnu--2005@xxxxxxxxxxxxxxxxxxxxxxxxx/miles@xxxxxxxxxxxxxxxxx Boy thats a long url. /me appreciates bzr more every way. :) > > -miles > -- > Do not taunt Happy Fun Ball. -- James Blackwell | Life is made of the stuff that hasn't killed Tell someone a joke! | you yet. - yours truly ---------------------------------------------------------------------- GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D 247A 8A55 DA73 0635 7400
Date: September 04, 2005
From: Miles Bader <snogglethorpe@xxxxxxxxx>
In-reply-to:
<87k6hwxy4i.fsf@xxxxxxxxxxxx>
References:
<m2fyt216tk.fsf@xxxxxxxxxxxxxx> <1124721951.4309e51f428d0@xxxxxxxxxxxxxx> <873bosxpas.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <buo7je4w6in.fsf@xxxxxxxxxxxxxxxxxxxxxx> <871x494wk6.fsf@xxxxxxxxxxxx> <buo64tljoc4.fsf@xxxxxxxxxxxxxxxxxxxxxx> <87k6hwxy4i.fsf@xxxxxxxxxxxx>
2005/9/5, Tollef Fog Heen <tfheen@xxxxxx>: > * Miles Bader > > | Tollef Fog Heen <tfheen@xxxxxx> writes: > | > http://www.sourcecontrol.net/?action=pushaccount > | > > | > It requires you to jump through a few hoops to set up, but it works > | > fine (I just went through the procedure and tested it). > | > | Hmmm, thanks for the pointer. > | > | I couldn't get it to work though -- after creating a launchpad account > | and registering my ssh/gpg keys: > | > | $ tla make-archive --mirror miles@xxxxxxxxxxxxxxxxx > miles@xxxxxxxxxxxxxxxxxxxxxxxx > sftp://miles@xxxxxxxxxxxxxxxxx@mirrors.sourcecontrol.net/miles@xxxxxxxxxxxxxxxxx > | Permission denied (publickey). > | Error reading from server > > I think you need to add you SSH key in launchpad as well; that part > seems to be missing from the instructions. Actually I did add my ssh key (and also gpg keys), and indeed that's enough so that I can use the sftp program to connect to the server and create and delete files manually; it's just that "tla archive-mirror" doesn't work. -miles -- Do not taunt Happy Fun Ball.
Date: September 04, 2005
From: Tollef Fog Heen <tfheen@xxxxxx>
In-reply-to:
<buo64tljoc4.fsf@xxxxxxxxxxxxxxxxxxxxxx> (Miles Bader's message of "Thu, 01 Sep 2005 15:26:19 +0900")
References:
<m2fyt216tk.fsf@xxxxxxxxxxxxxx> <1124721951.4309e51f428d0@xxxxxxxxxxxxxx> <873bosxpas.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <buo7je4w6in.fsf@xxxxxxxxxxxxxxxxxxxxxx> <871x494wk6.fsf@xxxxxxxxxxxx> <buo64tljoc4.fsf@xxxxxxxxxxxxxxxxxxxxxx>
* Miles Bader Cc-ing jblack who is the maintainer | Tollef Fog Heen <tfheen@xxxxxx> writes: | > http://www.sourcecontrol.net/?action=pushaccount | > | > It requires you to jump through a few hoops to set up, but it works | > fine (I just went through the procedure and tested it). | | Hmmm, thanks for the pointer. | | I couldn't get it to work though -- after creating a launchpad account | and registering my ssh/gpg keys: | | $ tla make-archive --mirror miles@xxxxxxxxxxxxxxxxx miles@xxxxxxxxxxxxxxxxxxxxxxxx sftp://miles@xxxxxxxxxxxxxxxxx@mirrors.sourcecontrol.net/miles@xxxxxxxxxxxxxxxxx | Permission denied (publickey). | Error reading from server I think you need to add you SSH key in launchpad as well; that part seems to be missing from the instructions. -- Tollef Fog Heen ,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Date: September 04, 2005
From: David Kastrup <dak@xxxxxxx>
References:
<431ACDD3.6020800@xxxxxx>
Sven Joachim <sven_joachim@xxxxxx> writes: > In GNU Emacs 22, Auto Compression mode is enabled by default. Therefore > and because of the growing number of packages coming with Emacs, it > makes sense to compress the Elisp source in the emacs<version>-el > package, saving probably some 25-30 Megabytes of disk space. Also, in > a way these files are documentation, and that is usually compressed in > Debian. > > The only drawback is that Emacs won't find the Elisp source files if > the user disables auto-compression-mode; but I think few people will > want to do that. Looks like an exacerbation of the existing Debian policy to recklessly break things like byte-recompile-directory. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Date: September 04, 2005
From: Romain Francoise <rfrancoise@xxxxxxxxxx>
References:
<431ACDD3.6020800@xxxxxx>
Sven Joachim <sven_joachim@xxxxxx> writes: > In GNU Emacs 22, Auto Compression mode is enabled by > default. Therefore and because of the growing number of packages > coming with Emacs, it makes sense to compress the Elisp source in the > emacs<version>-el package, saving probably some 25-30 Megabytes of > disk space. Yep, it's been on my emacs-snapshot todo list since the beginning, I was waiting for things to settle down before implementing it. The XEmacs packages in Debian have done that for ages. I did some testing a few weeks ago, the installed size of the package goes from 40.5 MB down to 12.6 MB, which is pretty good. The negative side is that it makes compression in the .deb much less efficient so its size goes from 9.4 MB to 11 MB... I think it's a reasonable tradeoff. The other negative effect is that compressing 972 files takes a short while. On archs where the build lasts more than 6 hours, it might add a few more minutes... I guess now is as good a time as any to implement this since things are pretty stable, so I'll do it for the next snapshot. Thanks, -- ,''`. : :' : Romain Francoise <rfrancoise@xxxxxxxxxx> `. `' http://people.debian.org/~rfrancoise/ `-
Date: September 04, 2005
From: Sven Joachim <sven_joachim@xxxxxx>
In GNU Emacs 22, Auto Compression mode is enabled by default. Therefore and because of the growing number of packages coming with Emacs, it makes sense to compress the Elisp source in the emacs<version>-el package, saving probably some 25-30 Megabytes of disk space. Also, in a way these files are documentation, and that is usually compressed in Debian. The only drawback is that Emacs won't find the Elisp source files if the user disables auto-compression-mode; but I think few people will want to do that.
Date: September 01, 2005
From: Miles Bader <miles.bader@xxxxxxxxx>
In-reply-to:
<871x494wk6.fsf@xxxxxxxxxxxx> (Tollef Fog Heen's message of "Wed, 31 Aug 2005 23:37:45 +0200")
References:
<m2fyt216tk.fsf@xxxxxxxxxxxxxx> <1124721951.4309e51f428d0@xxxxxxxxxxxxxx> <873bosxpas.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <buo7je4w6in.fsf@xxxxxxxxxxxxxxxxxxxxxx> <871x494wk6.fsf@xxxxxxxxxxxx>
Tollef Fog Heen <tfheen@xxxxxx> writes: > http://www.sourcecontrol.net/?action=pushaccount > > It requires you to jump through a few hoops to set up, but it works > fine (I just went through the procedure and tested it). Hmmm, thanks for the pointer. I couldn't get it to work though -- after creating a launchpad account and registering my ssh/gpg keys: $ tla make-archive --mirror miles@xxxxxxxxxxxxxxxxx miles@xxxxxxxxxxxxxxxxxxxxxxxx sftp://miles@xxxxxxxxxxxxxxxxx@mirrors.sourcecontrol.net/miles@xxxxxxxxxxxxxxxxx Permission denied (publickey). Error reading from server [The commands given in the instructions also seem to be wrong...] -Miles -- ((lambda (x) (list x x)) (lambda (x) (list x x)))