Re: emacsen-common 2.0.4 - acceptable for wheezy?
On 10.01.2013 03:06, Rob Browning wrote: "Adam D. Barratt" writes: Thanks for the review. Rob - please feel free to go ahead. emacsen-common 2.0.5 has been uploaded to unstable. Please let me know if you have any trouble. Unblocked; thanks. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/559d722cb5d7e492ff9b50068f217...@mail.adsl.funky-badger.org
Re: emacsen-common 2.0.4 - acceptable for wheezy?
"Adam D. Barratt" writes: > Thanks for the review. Rob - please feel free to go ahead. emacsen-common 2.0.5 has been uploaded to unstable. Please let me know if you have any trouble. 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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txqpag9y@trouble.defaultvalue.org
Re: emacsen-common 2.0.4 - acceptable for wheezy?
On Sun, 2012-12-30 at 12:50 +0100, intrigeri wrote: > Rob Browning wrote (13 Dec 2012 02:44:00 GMT) : > > +emacsen-common (2.0.5) unstable; urgency=low > > + > > [...] > > +the install was old-style or new-style. Now it should invoke each > > +package's install script based on whether or not the package itself is > > +new-style or old-style, > > s/ or not// [...] > > as determined by the presence or absence of > > +the policy-required /usr/lib/emacsen-common/packages/compat/PACAKGE > > s/PACAKGE/PACKAGE/ [...] > I'm assuming these ones are the same changes already reviewed as part > of 2.0.4, and the other (new) changes to emacs-package-install look > good to me, so I recommend the Release Team ACKs this > pre-unblock request. Thanks for the review. Rob - please feel free to go ahead. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1357163092.28716.18.ca...@jacala.jungle.funky-badger.org
Re: emacsen-common 2.0.4 - acceptable for wheezy?
Hi Rob, Rob Browning wrote (13 Dec 2012 02:44:00 GMT) : > OK, so here's the new version (2.0.5). Thank you. > diff -Nru emacsen-common-2.0.3/debian/changelog > emacsen-common-2.0.5/debian/changelog > --- emacsen-common-2.0.3/debian/changelog 2012-05-22 22:55:35.0 > -0500 > +++ emacsen-common-2.0.5/debian/changelog 2012-12-12 20:21:04.0 > -0600 > @@ -1,3 +1,42 @@ > +emacsen-common (2.0.5) unstable; urgency=low > + > [...] > +the install was old-style or new-style. Now it should invoke each > +package's install script based on whether or not the package itself is > +new-style or old-style, s/ or not// > as determined by the presence or absence of > +the policy-required /usr/lib/emacsen-common/packages/compat/PACAKGE s/PACAKGE/PACKAGE/ > +file. Thanks to Sébastien Villemot for the > +report. (closes: #693472) I find it odd that this changelog entry closes the same bug twice, but well. > diff -Nru emacsen-common-2.0.3/debian-startup.el > emacsen-common-2.0.5/debian-startup.el I'm assuming these ones are the same changes already reviewed as part of 2.0.4, and the other (new) changes to emacs-package-install look good to me, so I recommend the Release Team ACKs this pre-unblock request. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85han3hi7k@boum.org
Re: emacsen-common 2.0.4 - acceptable for wheezy?
"Adam D. Barratt" writes: > On Sun, 2012-12-09 at 17:03 -0600, Rob Browning wrote: >> And when I submit 2.0.5 here, should I include the debdiff against >> 2.0.4, or the full debdiff against what's currently in wheezy (i.e >> including the 2.0.4 and 2.0.5 diffs)? > > We'd like at least the latter for review purposes; feel free to include > an incremental debdiff as well if you think it'd help / be useful. OK, so here's the new version (2.0.5). Note that the new (2.0.5 specific) changes have also been examined and tested by Sébastien Villemot, which you can see at the end of the bug thread here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693472 Please let me know if I you think I should proceed with an upload to unstable (for wheezy). diff -Nru emacsen-common-2.0.3/debian/changelog emacsen-common-2.0.5/debian/changelog --- emacsen-common-2.0.3/debian/changelog 2012-05-22 22:55:35.0 -0500 +++ emacsen-common-2.0.5/debian/changelog 2012-12-12 20:21:04.0 -0600 @@ -1,3 +1,42 @@ +emacsen-common (2.0.5) unstable; urgency=low + + * Don't ignore dependency install scripts in emacs-package-install. The +previous code didn't actually update the script name properly in the +loop where it was trying to install all of an add-on package's +dependencies. As a result, none of the dependencies' install scripts +were actually invoked. Thanks to Sébastien Villemot + for tracking down the problem, and providing +the patch. (closes: #693472) + + * Invoke each add-on install script correctly as new-style or old-style. +Previously, emacs-package-install would invoke all of the add-on +install scripts in a dependency chain as either old-style or +new-style, based solely on whether or not the package that triggered +the install was old-style or new-style. Now it should invoke each +package's install script based on whether or not the package itself is +new-style or old-style, as determined by the presence or absence of +the policy-required /usr/lib/emacsen-common/packages/compat/PACAKGE +file. Thanks to Sébastien Villemot for the +report. (closes: #693472) + + -- Rob Browning Wed, 12 Dec 2012 20:15:05 -0600 + +emacsen-common (2.0.4) unstable; urgency=low + + * Don't use the obsolete calc package as a policy example. +Thanks to "A. N. Other" for the report. +(closes: #674181) + + * Don't override /usr/local/* load-path entries in debian-run-directories. +Previously, debian-run-directories would prepend all of the add-on +package paths to load-path, which meant that (in violation of Debian +policy) /usr/local wouldn't preceed the other entries. +Thanks to Hendrik Tews for the report and Kevin +Ryde for an initial suggested patch -- posted to +#454778. (closes: #676424) + + -- Rob Browning Sun, 02 Dec 2012 16:03:18 -0600 + emacsen-common (2.0.3) unstable; urgency=low * Move #DEBHEPLER# up in the postinst to avoid an emacs complaint about diff -Nru emacsen-common-2.0.3/debian-emacs-policy emacsen-common-2.0.5/debian-emacs-policy --- emacsen-common-2.0.3/debian-emacs-policy 2012-05-14 19:00:38.0 -0500 +++ emacsen-common-2.0.5/debian-emacs-policy 2012-05-27 12:20:49.0 -0500 @@ -312,11 +312,9 @@ It's been suggested, and is probably a good idea that maintainers switch to using autoload rather than load when possible in their - site-start.d files. - - For example, instead of (load "some-package"), you should use - autoloads for all the top level, user visible functions. Currently - the calc package has a good example of this. + site-start.d files. For example, instead of (load "some-package"), + you should use autoloads for all the top level, user visible + functions. diff -Nru emacsen-common-2.0.3/debian-startup.el emacsen-common-2.0.5/debian-startup.el --- emacsen-common-2.0.3/debian-startup.el 2012-02-11 16:06:54.0 -0600 +++ emacsen-common-2.0.5/debian-startup.el 2012-12-02 19:20:28.0 -0600 @@ -73,14 +73,14 @@ (nreverse result))) (defun debian-run-directories (&rest dirs) - "Load each file of the form XXfilename.el or XXfilename.elc in any of the dirs, where XX must be a number. The files will be run in alphabetical order. If a file appears in more than one of the dirs, then the earlier dir takes precedence, and a .elc file always supercedes a .el file of the same name." - (let* ((paths dirs) + (let* ((paths (mapcar 'copy-sequence dirs)) ; Ensure we have unique objects. + ;; Get a list of all the files in all the specified ;; directories that match the pattern. (files @@ -89,10 +89,9 @@ (lambda (dir) (directory-files dir nil "^[0-9][0-9].*\\.elc?$" t)) paths))) - + ;; Now strip the directory portion, remove any .el or .elc ;; extension. - (stripped-names (mapcar (la
Re: emacsen-common 2.0.4 - acceptable for wheezy?
On Sun, 2012-12-09 at 17:03 -0600, Rob Browning wrote: > And when I submit 2.0.5 here, should I include the debdiff against > 2.0.4, or the full debdiff against what's currently in wheezy (i.e > including the 2.0.4 and 2.0.5 diffs)? We'd like at least the latter for review purposes; feel free to include an incremental debdiff as well if you think it'd help / be useful. Thanks, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1355169272.25562.7.ca...@jacala.jungle.funky-badger.org
Re: emacsen-common 2.0.4 - acceptable for wheezy?
(Release team: please see the end of this message in particular...) intrigeri writes: > I removed a bit of the dust accumulated on my elisp skills and > reviewed the proposed changes. They look sane. > (Disclaimer: I'm not a release team member.) > > I've tested the proposed patch with emacs24 on Wheezy, and the diff > between the resulting load-path's (patched vs. unpatched) looks good: > /etc/emacs and /usr/local are now indeed listed before the add-ons > directories. That's great -- thanks. > It still looks like magic to me how the add-ons directories end up in > load-path at all, given it looks like we remove them in > debian-run-directories, immediately after letting the startup hooks > add them, but still, they do end up where they should, so I guess I'm > missing some bits of the Emacs startup big picture and I don't worry > about it :) Right. I believe newer versions of Emacs automatically add directories in some situations. As I recently mentioned elsewhere, I think it might be worth taking some time to review the way we handle the load-path in light of those changes, but that probably can (and should) wait until after Wheezy. >> +Thanks to Hendrik Tews for the report and Kevin >> +Ryde for an initial suggested patch -- posted to >> +#454778. (closes: #676424) > > Shouldn't #454778 be closed by this upload too, then? Possibly. Also... Release team: at this point, please hold off on 2.0.4 -- another bug has been discovered that should probably also be included in wheezy: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693472 I'm waiting to see if Sébastien has time to review my fix, and then I'll generate a 2.0.5 and resubmit. And when I submit 2.0.5 here, should I include the debdiff against 2.0.4, or the full debdiff against what's currently in wheezy (i.e including the 2.0.4 and 2.0.5 diffs)? 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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4mybzg0@trouble.defaultvalue.org
Re: emacsen-common 2.0.4 - acceptable for wheezy?
Hi, Rob Browning wrote (03 Dec 2012 01:41:26 GMT) : > I haven't uploaded it yet (wanted to ask first), but the debdiff is > below. Please let me know if I should proceed with an upload, or make > changes -- #674181 is minor (doc change); #676424 is serious. Thank you for tackling this RC bug. I removed a bit of the dust accumulated on my elisp skills and reviewed the proposed changes. They look sane. (Disclaimer: I'm not a release team member.) I've tested the proposed patch with emacs24 on Wheezy, and the diff between the resulting load-path's (patched vs. unpatched) looks good: /etc/emacs and /usr/local are now indeed listed before the add-ons directories. It still looks like magic to me how the add-ons directories end up in load-path at all, given it looks like we remove them in debian-run-directories, immediately after letting the startup hooks add them, but still, they do end up where they should, so I guess I'm missing some bits of the Emacs startup big picture and I don't worry about it :) > +Thanks to Hendrik Tews for the report and Kevin > +Ryde for an initial suggested patch -- posted to > +#454778. (closes: #676424) Shouldn't #454778 be closed by this upload too, then? Cheers! -- intrigeri -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85fw3jjkw3@boum.org
emacsen-common 2.0.4 - acceptable for wheezy?
I haven't uploaded it yet (wanted to ask first), but the debdiff is below. Please let me know if I should proceed with an upload, or make changes -- #674181 is minor (doc change); #676424 is serious. Thanks diff -Nru emacsen-common-2.0.3/debian/changelog emacsen-common-2.0.4/debian/changelog --- emacsen-common-2.0.3/debian/changelog 2012-05-22 22:55:35.0 -0500 +++ emacsen-common-2.0.4/debian/changelog 2012-12-02 19:20:40.0 -0600 @@ -1,3 +1,19 @@ +emacsen-common (2.0.4) unstable; urgency=low + + * Don't use the obsolete calc package as a policy example. +Thanks to "A. N. Other" for the report. +(closes: #674181) + + * Don't override /usr/local/* load-path entries in debian-run-directories. +Previously, debian-run-directories would prepend all of the add-on +package paths to load-path, which meant that (in violation of Debian +policy) /usr/local wouldn't preceed the other entries. +Thanks to Hendrik Tews for the report and Kevin +Ryde for an initial suggested patch -- posted to +#454778. (closes: #676424) + + -- Rob Browning Sun, 02 Dec 2012 16:03:18 -0600 + emacsen-common (2.0.3) unstable; urgency=low * Move #DEBHEPLER# up in the postinst to avoid an emacs complaint about diff -Nru emacsen-common-2.0.3/debian-emacs-policy emacsen-common-2.0.4/debian-emacs-policy --- emacsen-common-2.0.3/debian-emacs-policy2012-05-14 19:00:38.0 -0500 +++ emacsen-common-2.0.4/debian-emacs-policy2012-05-27 12:20:49.0 -0500 @@ -312,11 +312,9 @@ It's been suggested, and is probably a good idea that maintainers switch to using autoload rather than load when possible in their - site-start.d files. - - For example, instead of (load "some-package"), you should use - autoloads for all the top level, user visible functions. Currently - the calc package has a good example of this. + site-start.d files. For example, instead of (load "some-package"), + you should use autoloads for all the top level, user visible + functions. diff -Nru emacsen-common-2.0.3/debian-startup.el emacsen-common-2.0.4/debian-startup.el --- emacsen-common-2.0.3/debian-startup.el 2012-02-11 16:06:54.0 -0600 +++ emacsen-common-2.0.4/debian-startup.el 2012-12-02 19:20:28.0 -0600 @@ -73,14 +73,14 @@ (nreverse result))) (defun debian-run-directories (&rest dirs) - "Load each file of the form XXfilename.el or XXfilename.elc in any of the dirs, where XX must be a number. The files will be run in alphabetical order. If a file appears in more than one of the dirs, then the earlier dir takes precedence, and a .elc file always supercedes a .el file of the same name." - (let* ((paths dirs) + (let* ((paths (mapcar 'copy-sequence dirs)) ; Ensure we have unique objects. + ;; Get a list of all the files in all the specified ;; directories that match the pattern. (files @@ -89,10 +89,9 @@ (lambda (dir) (directory-files dir nil "^[0-9][0-9].*\\.elc?$" t)) paths))) - + ;; Now strip the directory portion, remove any .el or .elc ;; extension. - (stripped-names (mapcar (lambda (file) (if (string-match "\\.el$" file) @@ -105,34 +104,22 @@ files))) ;; Finally sort them, and delete duplicates - (base-names (debian-unique-strings (sort stripped-names 'string<))) - - (old-load-path load-path)) + (base-names (debian-unique-strings (sort stripped-names 'string< -;; Set a new load path with the directories specified in the -;; proper order, and first. -(let ((new-path (append paths load-path))) - (setq load-path new-path) - ;; Now load the files. "load" will make sure we get the byte - ;; compiled one first, if any, and will respect load-path's - ;; ordering. - (mapc - (lambda (file) - (condition-case err - (load file nil) - (error (message "Error while loading %s: %s" - file (error-message-string err) - base-names) - ;; 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)) +(setq load-path (append paths load-path)) ; Prefix paths temporarily. +;; Now load the files. "load" will make sure we get the byte +;; compiled one first, if any, and will respect load-path's +;; ordering. +(mapc + (lambda (file) + (conditio
