* Package name : emacs-snapshot Version : 22.whatever.would.be.fine Upstream Author : RMS & Co. * URL : http://www.fsf.org/... * License : GPL Programming Lang: lisp Description : emacs that is not very old Debian needs to revive their emacs-snapshot package. A once every three months snapshot would be fine. Six months OK too. You see, many users using the now disappeared emacs-snapshot package have already long ago got hooked, tailoring their .emacs files for emacs 22, and would go bananas if forced to rip all that up to go back to emacs 21. I am using the "daring" sid version of Debian, but it seems like "dusty" "woody". If it were that simple for lesser users such as myself to just roll-our-own, snap-in-place, then long ago the greater users would have not stopped packaging it or whatever.
Hi there. Is there any progress on this? Any updates? Thanks for any information, Rogério Brito.
Hi, you should look here to get a Debian package: http://emacs.orebokech.com/ Regards
retitle 429577 RFP: emacs-snapshot -- The GNU Emacs editor (development snapshot) noowner 429577 ! thanks Sorry I have not enough time for this package: (
close 429577 thanks Hello, This is an automatic mail sent to close this RFP. Your RFP wnpp bug is being closed because of the following reasons: - It hasn't seen any activity for the last 18 months. - The amount of RFPs on the Debian BTS is huge and we need to clean up a bit the place. As this an automatic procedure, it could of course have something wrong and probably it would be closing some bugs that are not intended by owners and submitters to be closed, for example if the RFP is still of your interest, or there has been some kind of activity around it. In that case, please do not hesitate to reopen the bug! To re-open it, you simply have to mail control@bugs.debian.org with a body text like this: reopen 123456 thanks bts Replacing '123456' for the number of your RFP bug. The subject of the mail is ignored. Or if you have any kind of problems when dealing with the BTS, feel free to contact me and I'd be more than happy to help you on this: <lucas@debian.org>. Thanks for your cooperation,
Hi, [Cc'ing the ITP FTR] I have almost finished preparing emacs-snapshot and temporarily pushed it there, so please have a look when you have some time as I may have messed things around ;-): https://salsa.debian.org/arnau/deb-emacs I have a few questions though: * bin_priority (for update-alternatives): I think it would make sense to have an higher one for emacs-snapshot, what about a number big enough so it doesn't clash with future stable release (such as 999)? * Currently emacs-snapshot version is: 2:YYYYMMDD-<LATEST_AVAILABLE_TAG>-g<MASTER_COMMIT_ID>-1 Considering that this is not really the LATEST_AVAILABLE_TAG but MASTER_COMMIT_ID at the time of packaging and in order to shorten the version which is currently rather long, MASTER_COMMIT_ID only should be enough, isn't it? This would mean having something like this after bumping the epoch and where the first '-1' is only in case of we upload two different Git snapshots on the same day: 3:YYYYMMDD-1+git<MASTER_COMMIT_ID>-1 What do you think? * I put myself as Maintainer, and Rob and Dima as Uploaders, but if either Rob or Dima wish to be in the Maintainer field, please let me know as either is fine to me. * I was thinking about having deb-emacs repository for both emacs25 and emacs-snapshot in collab-maint Git (as emacs.git) instead of a user repository. What do you think? * Rob: I have made several changes to emacs25 branch, feel free to merge them if they look fine to you: https://salsa.debian.org/arnau/deb-emacs/commits/deb/emacs25/d/sid/master And some packaging questions I will add to debian/README.source: * Dima is using gbp-pq and Rob git-dpm. In order to keep it as close as possible to emacs25 packaging, I have been using git-dpm. I don't really well both of them as this is the first time I use them so I have absolutely no opinion on this. Dima: is that ok? Rob: I ran the following command after importing patches from emacs25 and merging them with the ones from emacs-snapshot from Dima: $ git-dpm init --record-patch-name ../emacs-snapshot_20180414-1+git836dce6.orig.tar.xz deb/emacs-snapshot/d/sid/upstream However, I'm not so familiar with git-dpm, so would you mind explaining how you use it for emacs25? * Rob: I followed your naming scheme for branches and tags, thus: + Branches: deb/emacs-snapshot/d/sid/master deb/emacs-snapshot/d/sid/upstream + Tags: deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 * Rob: Could you please explain how you remove non-DFSG documentation (such as emacs.texi) from the Git repository? * Here is what I have been using to create a new upstream release from deb/emacs-snapshot/d/sid/master branch: $ git tag -s -m "Upstream tagged for Debian version 20180414-1+git836dce6." deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 deb/emacs-snapshot/d/sid/upstream $ gbp buildpackage --git-builder=/bin/true --git-upstream-tree=deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 => Thanks to debian/gbp.conf I added, this will automatically generate the tarball with pristine-tar. If that's ok, maybe debian/gbp.conf should be added to emacs25 branch too? Cheers,
Arnaud Fontaine <arnau@debian.org> writes:
Could you repost the questions that I don't sufficiently address below
to debian-emacsen@lists.debian.org? I think there are people there who
should also see them, particularly those like David and Sean who are
working on the broad add-on packaging effort.
For the moment I'd prefer to keep the "emacs25" (soon to be "emacs"[1])
flavor repository separate, which might suggest creating a collab-maint
emacs-snapshot repository for now, if that's what you'd like.
[1] In case you weren't already aware, we're about to unversion the
emacsXY package to just be "emacs". It's possible that won't affect
your work too seriously, though it does involve a bunch of changes
to the emacs25 debian/ files. As part of that, the "emacsXY" binary
package is becoming "emacs-gtk" because we're also moving the
"emacs" metapackage into the upcoming unversioned emacs source
package.
I say "we" because although I'm handling the code, David, Sean,
etc. have been helping figure out the details.
Appreciated -- my current plan is to finish the unversioning, and then
look back at what's pending elsewhere, emacs 26, bugs, etc. I'd guess
that it might make sense for you to rebase at that point (or at least
compare the changes), and then we can see where we stand.
I'm more than happy to attempt to minimize differences between
emacs-snapshot and emacs when we can, and I expect I should have more
time to help in a few weeks. But regardless, we should be able to
resolve your more immediate questions on debian-emacsen soon.
Thanks
Hi, Ok. Ok. There are not so many changes and most of them are for debian/copyright which is not related to your work on unversioning the emacsXY package. Would you mind at least applying the changes I did which does not clash with your work? Cheers,
[Resending this email to debian-emacsen@ as per Rob's request]
Hi,
I have almost finished preparing emacs-snapshot[0] and as I said to Rob,
my plan is to keep emacs-snapshot package as close as possible to
emacsXY package. I know that you've been working on unversioning emacs
package (BTW Where is that repository?).
I have a few questions before uploading emacs-snapshot though:
* bin_priority (for update-alternatives): I think it would make sense
to have an higher one for emacs-snapshot, what about a number big
enough so it doesn't clash with future stable release (such as 999)?
* I have made several changes to emacs25 branch, feel free to merge
them if they look fine to you (mostly debian/copyright work and
fixing lintian warnings):
https://salsa.debian.org/arnau/deb-emacs/commits/deb/emacs25/d/sid/master
And some packaging questions I will document in debian/README.source:
* Do you plan to keep using git-dpm? (I'm asking because Dima, the
current packager of emacs-snapshot, is using gbp-pq. I have no
preference/opinion on this subject, just asking)
I ran the following command after importing patches from emacs25 and
merging them with the ones from emacs-snapshot from Dima:
$ git-dpm init --record-patch-name ../emacs-snapshot_20180414-1+git836dce6.orig.tar.xz deb/emacs-snapshot/d/sid/upstream
However, I'm not so familiar with git-dpm, so would you mind
explaining how you use it for emacs25/unversioned emacs?
* I followed deb-emacs25[1] naming scheme for branches and tags, thus:
+ Branches:
deb/emacs-snapshot/d/sid/master
deb/emacs-snapshot/d/sid/upstream
+ Tags:
deb/emacs-snapshot/v/upstream/20180414-1+git836dce6
I guess unversioned emacs Git repository follows this scheme too,
right?
* Could you please explain how you remove non-DFSG documentation (such
as emacs.texi) from the Git repository?
* Here is what I have been using to create a new upstream release from
deb/emacs-snapshot/d/sid/master branch:
$ git tag -s -m "Upstream tagged for Debian version 20180414-1+git836dce6." deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 deb/emacs-snapshot/d/sid/upstream
$ gbp buildpackage --git-builder=/bin/true
--git-upstream-tree=deb/emacs-snapshot/v/upstream/20180414-1+git836dce6
=> Thanks to debian/gbp.conf I added, this will automatically
generate the tarball with pristine-tar. If that's ok, maybe
debian/gbp.conf should be added to emacs25/unversioned emacs
branch too?
Cheers,
Arnaud Fontaine <arnau@debian.org> writes: How many of the existing add-on packages in sid have you tested with your emacs-snapshot package? Do you have some plan to prevent/manage breakage of add-ons by a new upload of emacs-snapshot? It seems like every upload is potentially like a library transition, in that changes in emacs tend to break add-on packages. d
Hi, I use it myself on a daily basis for a few months (and Dima for much longer so he may know more than me about that) with around 20 add-ons. Except the fact that old-style backquotes have been removed for which I have a few patches ready (and which is something that will have to be deal for emacs26 anyway AFAIK), I have not had any problem so far. Anyhow, emacs-snapshot will only be available in sid/experimental and, except 4 source packages, all of them don't Build-Depends on emacs-snapshot. Also, most of the time, add-ons breakage to expect are on deprecated/removed interfaces (such as old-style backquotes) which is something that will have to be dealt anyway on new Emacs stable releases. But I get your point and indeed there need to be a plan to check before each upload of emacs-snapshot whether it breaks add-ons. A shell script installing in a clean chroot emacs-snapshot to be uploaded and all available add-ons in the archive would probably be enough and fairly easy to write? Cheers,
Arnaud Fontaine <arnau@debian.org> writes: It would be great to have. Rob: how do you usually do this in your packages?
Dima Kogan <dima@secretsauce.net> writes: As far as I know checking is a manual process with the stable emacs uploads. But there are many fewer such uploads. d
Hello, +1 I'd suggest installing the old emacs-snapshot and all addons, and then upgrading to the new emacs-snapshot. And then also test installing all addons without emacs-snapshot, and then installing the new emacs-snapshot. And perhaps installing the new emacs-snapshot and then all addons, too. I think you are aware, but just in case/for onlookers, the main issue is that all addons will get bytecompiled against the new Emacs by maintscripts, so if emacs-snapshot breaks addons, apt will be in a "failed to configure" state which can be a pain to recover from. I think there should be a warning in the package description that the package is for fairly advanced users only -- I can see someone not really familiar with apt/dpkg installing it, and then finding their system in a state from which they don't know how to back out. Unstable has garnered a reputation for actually being quite stable...
Arnaud Fontaine <arnau@debian.org> writes: The unversioning is nearly finished, so I suspect the thing to do is for me to finish the work, and then we'll look at your changes in that context. Any changes outside debian/ should be relatively unaffected, but others may require accommodation. In any case, I'll be happy to work with you on that once we're there. Unless something unexpected happens, I expect to upload the unversioned packages in the next week or so, if not sooner. Thanks
David Bremner <david@tethera.net> writes: Right. At the moment, I don't have any package-level automated testing.
Rob Browning <rlb@defaultvalue.org> writes: Great, thanks! Let me know when it has been pushed so I can merge/rebase my changes. I will probably have a few more by then as there are a few more Lintian warnings that I want to fix before uploading emacs-snapshot to NEW...
Hi, I no longer have an interest to maintain this package so I'm retitling it as RFP. The work done is not lost though and still available there if anyone wants to take over (and there is also a TODO list in the previous messages): https://salsa.debian.org/arnau/deb-emacs Cheers,