Re: dpkg trigger questions (and/or broader emacs add-on options)

triggering. This proposal inverts that. OK, I'll rethink the arrangements with that in mind. And just to double-check. It sounds like "postinst trigger" invocations can expect their deps to be configured. Once triggered, is there any ordering with respect to the "postinst trigger" invocations for multiple interested/awaiting packages, or is that "undefined"? Thanks much -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: dpkg trigger questions (and/or broader emacs add-on options)

-assess-rebuild All add-ons will be sensitive to that trigger, and will use the installed state files to reinstall for the relevant flavors. Whenever an add-on changes, remove the configured files for all reverse dependency add-ons, and trigger emacsen-common-add-on-assess-rebuild. Each add on and flavor package must include the relevant (empty) emacsen-common state directories. # Background: https://people.debian.org/~srivasta/MaintainerScripts.html#sec-6 https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: emacsen-common triggers rewrite

Rob Browning writes: > Sounds reasonable -- any chance y'all are going to have someone who > might know handy at debconf? Oh, and if you do happen to chat with anyone dpkg-related, as an alternative, it might be handy if we had a tool (dpkg or other) that could properly sort a list

Re: emacsen-common triggers rewrite

27;all are going to have someone who might know handy at debconf? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: emacsen-common triggers rewrite

also did some testing in a VM, and the ordering was respected for some test packages I created, but of course that's not a promise. Thanks for taking a look. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2

Re: [PATCH 0/4] Initial xemacs21 patches to support emacs unversioning

Mark Brown writes: > Sorry about the long delay in getting to these - they look good to me, > I'll apply them. No worries. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14D

Re: Unversioned Emacs can be uploaded to unstable

Sean Whitton writes: > Here at DebCamp, we think unversioned Emacs can be moved from > experimental to unstable. OK, I'll consider making the move fairly soon. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E

Re: Unversioned emacs packages uploaded to experimental

xemacs dir, and then symlink the one emacs needs over into /usr/share/emacs/site-lisp. I suspect either approach will work. Assuming I've understood the situation correctly, hope this helps. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676

Re: Unversioned emacs packages uploaded to experimental

Rob Browning writes: > I haven't yet, but I'll push the updated git refs to > https://salsa.debian.org/rlb/deb-emacs when I get a chance. ...the refs have been pushed. > Mark and I also plan to finish working out some adjustments for > xemacs21. Oh, and note that emacse

[PATCH 2/4] 00debian.el: set gnus-nntpserver-file and mail-host-address

As of 3.0.0, these are no longer handled by emacsen-common. --- debian/00debian.el | 11 +++ 1 file changed, 11 insertions(+) diff --git a/debian/00debian.el b/debian/00debian.el index 681afea..87508d5 100644 --- a/debian/00debian.el +++ b/debian/00debian.el @@ -6,6 +6,17 @@ emacs-prog

[PATCH 4/4] configure.in: add gentoo patch to fix header lookup

--- configure.in | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/configure.in b/configure.in index 88da2de..d708e7b 100644 --- a/configure.in +++ b/configure.in @@ -2866,8 +2866,12 @@ EOF * ) val=1 ;; esac dnl Avoid re-AC_DEFINE-ing xmkmf symbols

[PATCH 1/4] Load debian-startup from new emacsen-common location

--- debian/PackagesMakefile.in | 1 - debian/control | 8 +++ debian/debian-rundir.el| 60 -- debian/site-start.el.in| 29 +- 4 files changed, 5 insertions(+), 93 deletions(-) delete mode 100644 debian/debia

[PATCH 3/4] Given new policy and emacsXY unversioning drop shared dirs

--- debian/00debian.el | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/debian/00debian.el b/debian/00debian.el index 87508d5..fd06986 100644 --- a/debian/00debian.el +++ b/debian/00debian.el @@ -83,10 +83,6 @@ starting with a '.'" (dir-and-all-good-subs (

[PATCH 0/4] Initial xemacs21 patches to support emacs unversioning

Here's what I have so far, which might or might not be everything we need. Mark, when you get a chance, could you please take a look and see what you think? Thanks Rob Browning (4): Load debian-startup from new emacsen-common location 00debian.el: set gnus-nntpserver-file and mail

Unversioned emacs packages uploaded to experimental

;. I haven't yet, but I'll push the updated git refs to https://salsa.debian.org/rlb/deb-emacs when I get a chance. Mark and I also plan to finish working out some adjustments for xemacs21. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1F

Re: Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)

David Bremner writes: > As far as I know checking is a manual process with the stable emacs > uploads. But there are many fewer such uploads. Right. At the moment, I don't have any package-level automated testing. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of

Re: Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)

acs-X) \ <(git ls-files --with-tree emacs-Y) | less ...rm new files non-dfsg files, i.e. anything with gfdl invariants (front/back/sections), etc. - Check path changes (i.e. new/deleted paths, etc.). Check deleted-by-us to make sure license hasn't chan

RM: emacs24 -- ROM; replaced by emacs25

Package: ftp.debian.org User: release.debian@packages.debian.org Usertags: rm I think we may have finally addressed all of the relevant dependencies. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as

Re: Emacs packaging repository?

n debian/patches/. git-dpm manages the patches as a temporary git branch, which you can see if you're on say deb/emacs25/d/sid/master and you run "git-dpm checkout-patched". But there's no need to mess with git-dpm if you just want to send patches. -- Rob Browning rlb @defaultv

Re: Bug#851823: Changing default emacs to 25 to allow emacs24 removal -- RoM

ting on the removal of emacs24 or the switch of emacs-defaults to emacs25 (or both)? [1] Now I'm going to try to fix what I think is the same issue in emacs24, i.e. changes to libc/malloc that caused emacs to start crashing frequently. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.

Changing default emacs to 25 to allow emacs24 removal -- RoM

kages are indeed the only broken depends. [1] https://wiki.debian.org/Emacs25InStretch Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Wondering about possibility of removing emacs24 from stretch

tead of emacs24. Summary of our findings: https://wiki.debian.org/Emacs25InStretch Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Wondering about possibility of removing emacs24 from stretch

e'll be able to handle most of the rest by Sunday. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Wondering about possibility of removing emacs24 from stretch

Rob Browning writes: > And at the moment, we have: > > First category: > - two packages that are likely fine once the deps are broadened > - five still to evaluate > Update regarding the second category: - ten packages that appear fine (plus or minus a couple

Re: Planning to change emacs-defaults (emacs) to emacs25 soon

Bill Allombert writes: > The transition freeze was the 5 of November, so I suggest you ask the > opinion of the release team before proceeding. Done, and thanks. (Message presenting the situation sent to debian-release and debian-emacsen.) -- Rob Browning rlb @defaultvalue.o

Wondering about possibility of removing emacs24 from stretch

Of course if after testing, that doesn't appear to be the case, then we can just leave things as-is, but I think we'd all be substantially better off if we can avoid having to support both emacs24 and emacs25 for the lifetime of stretch. Thanks -- Rob Browning rlb @defaultvalue.org a

Re: Planning to change emacs-defaults (emacs) to emacs25 soon

as-is, but now that we've resolved the emacs25 stability issues, having to support emacs24 throughout stretch is an outcome we'd all be better off avoiding if we can. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E

Planning to change emacs-defaults (emacs) to emacs25 soon

does matter (or might matter in the future), then the dependency should probably look more like this: emacs25-nox | emacs25 | emacs24 This will have the buildds use the lighter-weight emacs25-nox flavor, but will allow any emacs24 or emacs25 flavor already installed to satisfy the dependency (si

Re: RFC: flavored provides, i.e. emacs25ish

like maybe dh-elpa can just depend on emacs25 and forget about it? I'm guessing any variant should be fine for its build-time needs. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 1

Re: RFC: flavored provides, i.e. emacs25ish

ause virtual-only deps are disagreeable, e.g.: emacs25-nox | emacs25-any | emacs24-nox | emacs24-any [1] Which is also why (iirc) for a long time there was no emacs meta-package (because before emacs19 (I think), the Emacs package was just "emacs"). Thanks -- Rob Browning rlb @d

Re: RFC: flavored provides, i.e. emacs25ish

ny be plausible? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: RFC: flavored provides, i.e. emacs25ish

provide, but I suppose it's preferable for "apt install emacs25" to request the "preferred" Emacs variety for the host (right now, GTK+). Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as

Re: RFC: flavored provides, i.e. emacs25ish

Sean Whitton writes: > s/ish/like/ might be easier for non-native English speakers to grasp. Heh, yeah, I figured we probably wouldn't end up with that name, but good point regardless. I suppose we could be even more explicit with something like emacs25-variant. -- Rob Brow

RFC: flavored provides, i.e. emacs25ish

if xemacs wanted to participate, it would provide xemacs25ish, etc. Though for the moment, we don't need a provides that encompasses both. If we ever do, it would likely be emacsen25ish, or similar. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C

Re: Slimming emacs-nox

or so after > install, and sometimes run out of space when compiling > programs. Things I have to be mindful of include package caches, > installed locales, extra storage required by a program or library. I imagine you also know about zile? -- Rob Browning rlb @defaultvalue.org and @debian.

Slimming emacs-nox

cs24-nox packages and what we might want in a truly minimal package, then we could consider adding an emacs24-min or something, but such an addition should be weighed against the complexity it introduces. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C

Pondering adjustments to emacsen flavor info handling

). This approach depends on update-alternatives handling sets reasonably whose --slave links differ - which I haven't investigated yet. Thoughts? -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03

Re: proposal to (maybe) use "elpa-" package prefix for emacs lisp packages

at package build time (each add-on would have to have a build-dep on all of the relevant emacs* flavors). In the past, I believe that was considered too much archive bloat. Hope this helps. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4

Re: Bug#766868: haml-elisp: Fails to install with Emacs 24.4

might keep emacs24 24.4 out of jessie. One answer would be to patch css-mode, another would be to just remove css-mode (and html-helper-mode (last updated upstream in 2004) if it doesn't work with Emacs' built-in css-mode). Thoughts? Thanks -- Rob Browning rlb @defaultvalue.org and @d

Re: Bug#766868: haml-elisp: Fails to install with Emacs 24.4

eck Emacs's own > HTML mode(s?) once again. ...or perhaps html-helper-mode works with 24.4's css-mode? If so then html-helper-mode can just adjust its dependencies. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B

Re: emacs24 backport

give me a few weeks, but if that doesn't work out, then perhaps Bálint can handle it. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 --

Re: emacsen-install/emacsen-remove scripts

e handled by the add-on maintainer, whether by copying from an example, or starting from scratch. I'm certainly open to the idea of more automation where it's obvious there's a "right answer" (that will work for all add-ons -- current and future), or where its use can be

Re: emacsen-install/emacsen-remove scripts

y to fix some problems in post 2.0 policy/emacsen-common. That said, I don't know that dh_installemacsen does anything about the install/remove scripts, and in fact, it might be hard to do anything that would reliably cover all packages (whose install behaviors/tools probably vary). Thoug

emacsen-common: handling of add-on packages still broken in some cases

lify other relevant bits). Apologies for the churn, and thanks. I hope to get this sorted soon. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E

Re: emacsen-common 2.0.6 uploaded (new requirements for add-on packages)

Rob Browning writes: > There has also been one important policy change for add-on packages. > They are now required to manage their "installed" state file directly. > See debian-emacs-policy section 5B for further details, but here's the > relevant diff: Unpleasant ty

emacsen-common 2.0.6 uploaded (new requirements for add-on packages)

ed/ The postinst call must not be made until the package is completely configured and otherwise ready for use, and the prerm This should fix a problem caused when add-on packages were being installed at the same time as emacsen-common. Thanks -- Rob Browning rlb @defaultvalue.org

Re: emacsen-common 2.0 released -- major changes (including policy)

ince myself that Breaks would also be OK. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-emacsen-requ...@lists.debian.org with a subject of "unsubscribe".

Re: emacsen-common 2.0 released -- major changes (including policy)

nstalled/emacsen-common then /usr/lib/emacsen-common/emacs-package-remove --prerm gettext fi Obviously this work is quite new, and there may well be problems. Please let me know if/when you encounter any trouble. Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.

emacsen-common 2.0 released -- major changes (including policy)

st the relevant package(s) to follow the new requirements in debian-emacs-policy. See current /usr/share/doc/emacsen-common/debian-emacs-policy.gz for the details, and please let me know if you have any trouble. I wouldn't be surprised if we need adjustments. Thanks -- Rob Browning rlb @

Re: emacsen-common: Please symlink to the .el when byte compiling for each emacsen

Rob Browning writes: > I've finally added something to this effect for an upcoming release > (probably a 1.4.23 release unless I get the major 2.0.0 overhaul out > fairly quickly -- that's more or less working now): > > E) If an add-on package compiles any of its

emacsen-common: Please symlink to the .el when byte compiling for each emacsen

e I think existing policy requirements should already have the intended effect. Unless I'm forgetting something, add-on packages are already required to stick to the directories, and the directories are required to come first in the load path for each emacsen (which is enforced for add-ons

Re: Bug handling for removed emacs21/emacs22 packages?

ssigned to the current version when they still apply, or closed when you're sure the problem has been fixed. > See: http://wiki.debian.org/BugTriage I just scanned this, and from a quick look, it sounds reasonable to me. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG

Re: RFC: relaxation of debian-emacs-policy dependency requirements

ually actually correct... Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-emacsen-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contac

Re: RFC: relaxation of debian-emacs-policy dependency requirements

Rob Browning writes: >prerm: > rm -f /var/lib/ec/state/package/installed/PACKAGE > for flavor in /var/lib/ec/state/flavor/installed/* >/usr/lib/emacsen-common/packages/install/PACKAGE $flavor Obviously that should be remove/PACKAGE. -- Rob Browning rlb @defa

Re: RFC: relaxation of debian-emacs-policy dependency requirements

here that's the case, I'd prefer to handle them independently so we don't end up trying to tackle too much at once. (i.e. perhaps get the overhaul working first, then see how/if we can abstract the common cases in a way that really helps.) Thanks -- Rob Browning rlb @defaultvalue.

Re: RFC: relaxation of debian-emacs-policy dependency requirements

Rob Browning writes: > So I think I'm going to adjust the tree I've been hacking on to > implement this and see how it looks. Does anyone have any objections or > complaints? > > Here's what I'm planning (more or less): > > - Have a canonical sta

Re: RFC: relaxation of debian-emacs-policy dependency requirements

Rob Browning writes: > - Require all add-on packages to specify --postinst when calling > emacs-package-install from their postinst. That will make it > possible to detect updated add-on packages. > > - Require emacs flavors to call emacs-install with comparable >

Re: RFC: relaxation of debian-emacs-policy dependency requirements

Rob Browning writes: > I'd be quite happy if we really can eliminate any need for add-on > packages to depend on emacsen-common. The main objection I have to the > use of installed-flavors is that it's an implementation detail (and one > I've been thinking about c

Re: RFC: relaxation of debian-emacs-policy dependency requirements

2). The > > This is a real problem that current system cannot address I think this proposal, or something like it might. If the emacs postinst fires first, then the state files will tell emacsen-common to ignore the add-on package. Later, when the add-on package's preinst fires, it'

Re: RFC: relaxation of debian-emacs-policy dependency requirements

ot handle it this way. If we do relax the policy requirement, I'd rather abstract this a bit more, so that add-on packages don't directly depend on a detail of the current implementation, and commit emacsen-common to the maintenance of installed-flavors indefinitely. Thanks -- Rob Brow

Re: RFC: relaxation of debian-emacs-policy dependency requirements

Ian Jackson writes: > Rob Browning writes ("RFC: relaxation of debian-emacs-policy dependency > requirements"): >> After some investigation, it looks like we might be able to change >> policy to just require add-on packages to depend on emacsen-common, >> whi

RFC: relaxation of debian-emacs-policy dependency requirements

, if not all of the separate foo-el helper packages. Thoughts? -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-emacsen-requ...@lists.debian.org with a subject of "unsubscribe".

Re: Bug#539800: emacs23 should be built with GTK+, not Lucid

or remote servers.) Oh, we will certainly keep the nox build, and we'll also have a -lucid package in the next upload, which should be pretty soon. So we'll have emacs23, the GTK+ version, emacs23-lucid, the older version, and emacs23-nox, which will remain the same. Thanks -- R

Re: Bug#539800: emacs23 should be built with GTK+, not Lucid

cation for an additional emacs23-(lucid|athena) package. Thoughts? -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-emacsen-requ...@lists.debian.org with a subj

Re: emacs23 uploaded to unstable

Daniel Pittman writes: > 403 Forbidden: You don't have permission to access > /~rlb/tmp/emacs23/emacs23_23.1+1-2_i386.changes on this server. OK, that should be fixed now, though I may just take the packages down since it looks like they've made it to unstable. Thanks --

Re: emacs23 uploaded to unstable

Rob Browning writes: > Daniel Moerner writes: > >> Thanks for packaging this, I think you mean: >> >> http://alioth.debian.org/~rlb/tmp/emacs23/ >> >> Daniel > > Yes, and thanks. I've just uploaded 23.1+1-2 which fixes some significant probl

Re: emacs23 uploaded to unstable

Daniel Moerner writes: > Thanks for packaging this, I think you mean: > > http://alioth.debian.org/~rlb/tmp/emacs23/ > > Daniel Yes, and thanks. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0

Re: emacs23 uploaded to unstable

lb/public_html/tmp/emacs23/ Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-emacsen-requ...@lists.debian.org with a subject of "unsubscribe".

emacs23 uploaded to unstable

I've uploaded the first emacs23 packages (23.1+1-1) to unstable. Please file bugs as appropriate. Note that we have also begun the process of removing emacs21 from unstable/testing. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-

Re: Is any work happening on Emacs23 packages?

Rob Browning writes: > Hilko Bengen writes: > >> Emacs 23.1 is likely to be released RSNish[1], so I am wondering whether >> there are any ongoing efforts, apart from several inofficial >> emacs-snapshot packages, to get any of the 23.0.9x pre-releases >> packaged

Re: Is any work happening on Emacs23 packages?

itial packages of (currently) 23.0.96. Assuming I'm ready before the official release of 23.1, I'm planning to upload them to experimental, then transfer them to unstable when 23.1 comes out. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-11-

Re: Upcoming emacsen-common work

Rob Browning writes: > Just to let everyone know. Now that lenny has been released, I plan > to start uploading new versions of emacsen-common fairly soon -- I've > been looking at Agustin's work (and talking with him), and have > started going through his changes.

Upcoming emacsen-common work

or all of that work, as I get to it. I'm also planning to publish my git repository somewhere soon. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to

Re: Playing with a personal emacsen-common build

I'm certainly in favor of fixing up emacsen-common, and I should be in a better position to help. Also, since these changes won't go in lenny, we should have a reasonably free hand. Thanks very much for the help. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.u

Re: ITP: emacs.app -- The GNU Emacs editor on GNUstep

your package development, and I'm definitely curious, but I haven't made any decisions. The current quilt approach is fairly straightforward, if not very pretty. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-11-03 14DD 432F AE39 534D B5

Re: Trouble with byte-compiling .el files on Emacs update

'm fairly cautious when considering changes to emacsen-common and/or debian-emacs policy since there are many moving parts, and a lot of tricky details. As I recall, there are quite a lot of (possibly non-obvious) things that you can get wrong if you're not careful. -- Rob Browning rlb @d

emacs22 uploaded to experimental

that it's possible there might be some incompatible changes before emacs22 moves to unstable, but if so, I expect them to be minor. 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 8C7

Re: emacs22 Debian package?

ge at the moment. My normal course for accepting additional people would be the same one that Jérôme followed. He offered help, started submitting patches, and after a while, I added him as an uploader. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG sta

Re: Bug#329114: Please don't shadow emacs-snapshot packages

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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#329114: Please don't shadow emacs-snapshot packages

y 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] w

Re: An example Emacsen policy

at you mean correctly, this is just not allowed, and is not going to be supported. If the user wants this, they should be using /usr/local, or their own homedir, and we should make sure that works right. The admin/user is never supposed to mess with /usr/share directly on a Debian system. One oth

Re: Bug#198887: emacs21: envvars not being inherited everywhere

is in my ~/.gnomerc # This is ~/.gnomerc source ${HOME}/.bash_profile and I arrange for my .bash_profile to handle everything else as usual. Hope this helps. -- 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

Re: Bug#193439: emacsen-common: debian-emacs-policy and package setup in conffile

so include a directory where packages could place fragments. It's been a *long* time, but I don't recall thinking too hard about alternatives to /etc. Also, please let me know what things you think should be fixed wrt "Debian fighting Emacs". I'd be interesting in straight

Re: future of emacs20

time. In the end, if there's an upstream preference, I'll probably honor that. I'm not looking forward to it, but if it's the best solution, I might compromise with emacsXY and emacsXY-gtk or something... -- 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

Re: future of emacs20

27;m not all that happy about is the xaw3d scrollbars. I'm tempted to go back to the plain ones. They seemed cleaner and more functional to me. I suppose I'm also going to have to think about what (if anything) I might want to do about gtk as well... -- Rob Browning rlb @defaultvalue.o

Re: future of emacs20

That may be a better idea. I'll think about it for a little bit, and then I guess I'll post something to debian-devel once I know what I want to do. 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

future of emacs20

fficial decision yet, but I thought I'd bring it up here first. I suppose the options are for me to orphan it, for someone else to take it over, or for me to suck it up and get back to work on it. Thoughts? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previous

Re: Emacs info policy

Kirk Hilliard <[EMAIL PROTECTED]> writes: > A year ago Rob Browning started a short thread "Support for multiple > installed versions of a program."[1] discussing more of the issues > involved here, and I am trying to figure out what the status is now > and what work m

Re: emacs mode for running debuild, debc, and debi etc.

tten *again* why that restriction was there :> I'll put adding that rationale to debian-emacs-policy on my todo list. > It would be nice to work this out in a better way in the long run. Yeah I agree. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @

Re: emacs mode for running debuild, debc, and debi etc.

y take some design and implementation work, and until then, it's probably *not* OK for add-on packages to depend on emacsen-common. And definitely let me know if I'm wrong about the potential problems. Though if I am, we'll still need to audit the process before I could say for sure

Re: Proposed change: allow "Depends: emacsen-common".

Rob Browning <[EMAIL PROTECTED]> writes: > This change would provide an advantage for packages for which emacsen > support is just a minor additional and optional item, packages like > dpkg-dev (before dpkg-dev-el) and gettext, for example. They could > just add a dependency

Proposed change: allow "Depends: emacsen-common".

lled before the add-on packages tried to use it. Thoughts? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

Re: It's Huntin' Season

(load "/usr/share/foo-package/site-wide.el") # favorite frob color (load "/usr/share/foo-package/get-and-set-frob-color.el") etc. Thoughts? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

Re: It's Huntin' Season

uest. Just a reminder to everyone for add on packages to please try to migrate to the new method of adding to load-path. See the recent emacsen-common changelog for info. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

Support for multiple installed versions of a program.

p;repeatmerged=yes> See the end of the log for a part of the solution we've considered. Manoj, in particular has thought quite a bit about this. Thanks [1] I'm also planning to add support for multiple versions of guile soon. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

Re: Bug#65320: gettext: fails on postinst

be such a tragedy ]. If you're OK with that, I'm OK with that -- it'll probably save us some head-scratching. Thanks -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

Grrr -- If I've appeared strangely unresponsive on this list.

hat I wasn't in fact subscribed. I don't know when this happened, but I suspect it was when I switched to my current domain. Anyway, if I've missed things or appeared to ignore people, apologies. Please feel free to badger me again since I may not have recevied the relevant mail. --

Re: Bug#65320: gettext: fails on postinst

d, and emacs21 is removed and emacsen-common is removed? The new (relaxed) dependency arrangement would allow that. Is that OK? Thanks -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

Re: Bug#65320: gettext: fails on postinst

t a problem either, since you couldn't actually use foo anyway. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

Re: A flaw in current emacsen package setup?

to either check (fboundp 'debian-pkg-add-load-path-item) before calling this function, or add a dependency on emacsen-common (>= 1.4.14). -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

  1   2   >