Emacs trunk binary on Dropbox

Emacs trunk binary on Dropbox

[Sebastien Vauban]

Hello Dani,

Did you stop to publicly make Windows binaries of Emacs trunk available on
Dropbox, or did you move its location?

That was *very* practical for many of us...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Emacs trunk binary on Dropbox

[Dani Moncayo]

On Tue, Oct 1, 2013 at 9:55 AM, Sebastien Vauban
<sva-news@mygooglest.com> wrote:
> Hello Dani,
>
> Did you stop to publicly make Windows binaries of Emacs trunk available on
> Dropbox, or did you move its location?

I moved its location.  See
   http://lists.gnu.org/archive/html/help-emacs-windows/2013-09/msg00005.html

-- 
Dani Moncayo

Re: Emacs trunk binary on Dropbox

[Sebastien Vauban]

Hello Dani,

Dani Moncayo wrote:
> On Tue, Oct 1, 2013 at 9:55 AM, Sebastien Vauban wrote:
>> Did you stop to publicly make Windows binaries of Emacs trunk available on
>> Dropbox, or did you move its location?
>
> I moved its location.  See
>    http://lists.gnu.org/archive/html/help-emacs-windows/2013-09/msg00005.html

I somehow had missed your announcement. Thanks a lot for your continued help
providing us with fresh Emacs binaries...

Tiens, I now don't see any Bazar revision anymore:

  ╭────
  │ emacs-bzr-version is a variable defined in `version.el'.
  │ Its value is nil
  │ 
  │ Documentation:
  │ String giving the bzr revision from which this Emacs was built.
  │ The format is: [revno] revision_id, where revno may be absent.
  │ Value is nil if Emacs was not built from a bzr checkout, or if we could
  │ not determine the revision.
  ╰────

Is this normal?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Emacs trunk binary on Dropbox

[Dani Moncayo]

> Tiens, I now don't see any Bazar revision anymore:
>
>   ╭────
>   │ emacs-bzr-version is a variable defined in `version.el'.
>   │ Its value is nil
>   │
>   │ Documentation:
>   │ String giving the bzr revision from which this Emacs was built.
>   │ The format is: [revno] revision_id, where revno may be absent.
>   │ Value is nil if Emacs was not built from a bzr checkout, or if we could
>   │ not determine the revision.
>   ╰────
>
> Is this normal?

I guess this is due to the fact that now I'm making my builds from the
git repository [1], instead of the bzr branch.

Anyway, if you want to know the bzr revno associated with a binary,
just look at the archive name, as explained in the file
"snapshots/README":

  The archives in this directory are named according to this pattern:

     emacs-rREVNO-YYYYMMDD-API-bin.zip

  where:
    * REVNO is the bzr revision (of the trunk branch) that was built.
    * YYYYMMDD is the commit date of the above revision.
    * API is the host OS API (always "w32" for now).


--- Footnotes ---

[1] http://savannah.gnu.org/git/?group=emacs

-- 
Dani Moncayo

Re: Emacs trunk binary on Dropbox

[Sebastien Vauban]

Dani Moncayo wrote:
>> Tiens, I now don't see any Bazar revision anymore:
>>
>>   ╭────
>>   │ emacs-bzr-version is a variable defined in `version.el'.
>>   │ Its value is nil
>>   │
>>   │ Documentation:
>>   │ String giving the bzr revision from which this Emacs was built.
>>   │ The format is: [revno] revision_id, where revno may be absent.
>>   │ Value is nil if Emacs was not built from a bzr checkout, or if we could
>>   │ not determine the revision.
>>   ╰────
>>
>> Is this normal?
>
> I guess this is due to the fact that now I'm making my builds from the
> git repository [1], instead of the bzr branch.
>
> Anyway, if you want to know the bzr revno associated with a binary,
> just look at the archive name.

Yes, I knew that; but it's simply because I had taken the habit of displaying
the revision number in the window title, so that every screenshot would
explicitly display with which version the problem occurred.

--8<---------------cut here---------------start------------->8---
  (setq frame-title-format
        (format "Emacs %s rev:%s pid:%d"
                emacs-version
                (ignore-errors
                  (replace-regexp-in-string " .*" "" emacs-bzr-version))
                (emacs-pid)))
--8<---------------cut here---------------end--------------->8---

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Emacs trunk binary on Dropbox

[Dani Moncayo]

> Yes, I knew that; but it's simply because I had taken the habit of displaying
> the revision number in the window title, so that every screenshot would
> explicitly display with which version the problem occurred.

I see.  Sorry for the inconvenience.

I've switched to git because I definitely prefer it to bzr (I've
learnt a bit of both of them).  And moreover, while bzr seems sort of
abandoned, git is very active and enjoys widespread adoption.

-- 
Dani Moncayo

Re: Emacs trunk binary on Dropbox

[Eli Zaretskii]

> Date: Tue, 1 Oct 2013 11:12:24 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: "help-gnu-emacs@gnu.org list" <help-gnu-emacs@gnu.org>
> 
> > Tiens, I now don't see any Bazar revision anymore:
> >
> >   ╭────
> >   │ emacs-bzr-version is a variable defined in `version.el'.
> >   │ Its value is nil
> >   │
> >   │ Documentation:
> >   │ String giving the bzr revision from which this Emacs was built.
> >   │ The format is: [revno] revision_id, where revno may be absent.
> >   │ Value is nil if Emacs was not built from a bzr checkout, or if we could
> >   │ not determine the revision.
> >   ╰────
> >
> > Is this normal?
> 
> I guess this is due to the fact that now I'm making my builds from the
> git repository [1], instead of the bzr branch.
> 
> Anyway, if you want to know the bzr revno associated with a binary,
> just look at the archive name, as explained in the file
> "snapshots/README":
> 
>   The archives in this directory are named according to this pattern:
> 
>      emacs-rREVNO-YYYYMMDD-API-bin.zip
> 
>   where:
>     * REVNO is the bzr revision (of the trunk branch) that was built.
>     * YYYYMMDD is the commit date of the above revision.
>     * API is the host OS API (always "w32" for now).

That's too bad, because now report-emacs-bug will not show the bzr
revision, and whoever reads the bug report has no idea from which zip
file the binary came.

Please reconsider the decision, or provide some way for your builds to
report the bzr revision.  TIA.

Re: Emacs trunk binary on Dropbox

[Dani Moncayo]

>> Anyway, if you want to know the bzr revno associated with a binary,
>> just look at the archive name, as explained in the file
>> "snapshots/README":
>>
>>   The archives in this directory are named according to this pattern:
>>
>>      emacs-rREVNO-YYYYMMDD-API-bin.zip
>>
>>   where:
>>     * REVNO is the bzr revision (of the trunk branch) that was built.
>>     * YYYYMMDD is the commit date of the above revision.
>>     * API is the host OS API (always "w32" for now).
>
> That's too bad, because now report-emacs-bug will not show the bzr
> revision, and whoever reads the bug report has no idea from which zip
> file the binary came.
>
> Please reconsider the decision, or provide some way for your builds to
> report the bzr revision.  TIA.

It would be nice if I could specify the bzr revno manually, for
example as a parameter to "configure" or "make", because having to
keep using bzr just for this little thing would also be too bad.

-- 
Dani Moncayo

Re: Emacs trunk binary on Dropbox

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

Must not that revision number be available somewhere in the mirror?
On Oct 1, 2013 6:09 PM, "Dani Moncayo" <dmoncayo@gmail.com> wrote:

> >> Anyway, if you want to know the bzr revno associated with a binary,
> >> just look at the archive name, as explained in the file
> >> "snapshots/README":
> >>
> >>   The archives in this directory are named according to this pattern:
> >>
> >>      emacs-rREVNO-YYYYMMDD-API-bin.zip
> >>
> >>   where:
> >>     * REVNO is the bzr revision (of the trunk branch) that was built.
> >>     * YYYYMMDD is the commit date of the above revision.
> >>     * API is the host OS API (always "w32" for now).
> >
> > That's too bad, because now report-emacs-bug will not show the bzr
> > revision, and whoever reads the bug report has no idea from which zip
> > file the binary came.
> >
> > Please reconsider the decision, or provide some way for your builds to
> > report the bzr revision.  TIA.
>
> It would be nice if I could specify the bzr revno manually, for
> example as a parameter to "configure" or "make", because having to
> keep using bzr just for this little thing would also be too bad.
>
> --
> Dani Moncayo
>
>

[-- Attachment #2: Type: text/html, Size: 1633 bytes --]

Re: Emacs trunk binary on Dropbox

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Must not that revision number be available somewhere in the mirror?

$ git notes show d079fb16c40905c3ebb5a53483dc17eb85d1577b
monnier@iro.umontreal.ca-20131001155253-f13ed73lrl2p8utj

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs trunk binary on Dropbox

[Eli Zaretskii]

> Date: Tue, 1 Oct 2013 18:08:42 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Sebastien Vauban <sva-news@mygooglest.com>, 
> 	Emacs development discussions <emacs-devel@gnu.org>
> 
> > That's too bad, because now report-emacs-bug will not show the bzr
> > revision, and whoever reads the bug report has no idea from which zip
> > file the binary came.
> >
> > Please reconsider the decision, or provide some way for your builds to
> > report the bzr revision.  TIA.
> 
> It would be nice if I could specify the bzr revno manually, for
> example as a parameter to "configure" or "make", because having to
> keep using bzr just for this little thing would also be too bad.

You need to set the value of emacs-bzr-version (a string) during
dumping.

Re: Emacs trunk binary on Dropbox

[Stephen J. Turnbull]

Dani Moncayo writes:

 > It would be nice if I could specify the bzr revno manually, for
 > example as a parameter to "configure" or "make", because having to
 > keep using bzr just for this little thing would also be too bad.

I don't own the code so won't quote it here, but XEmacs has a file
named "version.sh" which contains mostly static information about the
version: current major and minor, most recent patchlevel, beta status,
and something called "extra version info".  I forget how it's done (I
think it's in configure) but if hg is available, just do "hg id -i -n
>> version.sh", and then make includes that file so that the version
values are available in Make variables.  They may also be substituted
into config.h, I forget.  The latter would probably be easiest: add
a "version-extra-info" building variable to Lisp (in C), and add

#define VERSION_EXTRA_INFO @@VERSION_EXTRA_INFO@@

to config.h.in, and let configure do its thing using the bzr revision
number or revision id or both (I prefer both since people using bzr
who are off the mainline with local changes won't have useful revnos).

If you use a shell/make script, the tricky part is that it's essential
that the "extra_version_info=" line be last and unterminated with a
newline.

Presumably some similar could be done with lisp/version.el or
whatever as well.

I don't see why the maintainers would object to this, so feel free to
come up with a patch.