silex/master commit number

[ikappaki]

Hi,

I'm having an issue with silex/emacs:master that seems to be an Emacs bug, but I can't reproduce it with the latest emacs master branch cloned locally on my computer so as to verify.

Is there a way to get the commit number of which the emacs:master image has been build from, so I can use try to clone the same exact revision number locally? The emacs-repository-version is not set, probably because it is built from a source tarball.

Thanks!

[Silex]

From what I understand it's from commits like these https://github.com/purcell/nix-emacs-ci/commit/e44330eff29846ba56eb2d63fc84ed8812f9df11

@purcell you confirm? Wouldn't it make sense to have it updated more often?

[ikappaki]

From what I understand it's from commits like these purcell/nix-emacs-ci@e44330e

@purcell you confirm? Wouldn't it make sense to have it updated more often?

Thanks, i can confirm a1fa3d24d7f96542530f30c28daf9bf8aaaeae13 mentioned in the above has the bug, which must have been fixed on a later revision.

It would be great if the master container is updated more regularly/deterministically or/and if the image is build from a git checkout so that the emacs-repository-version and friends are set with the repo metadata. It will definitely save people from a lot of trouble:)

(For the record, this version was returning a bizarre cl struct tag for no apparent reason when byte-compile-and-loading a file for the first time -- in the case below the expect value for cl-struct-queue-tags should have been (queue) but it comes back as (#<symbol queue at 2152>) messing up with cl struct identification. It has been quite hard to figure this out from the docker image alone:

emacs -Q --batch --eval "(progn (package-initialize) (package-install 'queue) (when (boundp 'cl-struct-queue-tags) (warn \":ins %S\" cl-struct-queue-tags))   )"
# =>
Setting `package-selected-packages' temporarily since "emacs -q" would overwrite customizations
Setting `package-selected-packages' temporarily since "emacs -q" would overwrite customizations
Contacting host: elpa.gnu.org:443
Contacting host: elpa.gnu.org:443
  INFO     Scraping files for queue-autoloads.el... 
  INFO     Scraping files for queue-autoloads.el...done
Checking /home/chaos/.config/emacs/elpa/queue-0.2...
Compiling /home/chaos/.config/emacs/elpa/queue-0.2/queue-autoloads.el...
Compiling /home/chaos/.config/emacs/elpa/queue-0.2/queue-pkg.el...
Compiling /home/chaos/.config/emacs/elpa/queue-0.2/queue.el...

In toplevel form:
queue.el:47:2: Warning: Package cl is deprecated
queue.el:55:2: Warning: `defstruct' is an obsolete alias (as of 27.1); use `cl-defstruct' instead.
Done (Total of 1 file compiled, 2 skipped)
Package `queue' installed.
Warning (emacs): :ins (#<symbol queue at 2152>)

)

[purcell]

Yes, I'd quite like to have updates made more regularly, perhaps via a scheduled github action. It's a manual process so far.

[ikappaki]

Yes, I'd quite like to have updates made more regularly, perhaps via a scheduled github action. It's a manual process so far.

Hi @purcell, indeed, I've just noticed that in repo's readme:

snapshot builds aim to be a relatively recent commit on the Emacs master branch, and do not automatically give you the very latest Emacs revision available via Git. That would defeat binary caching, so the current plan is to periodically update the -snapshot builds manually. Send me a pull request to do this

and thank you for updating to the latest snapshot with https://github.com/purcell/nix-emacs-ci/pull/69 :)

Hi @Silex, I've noticed what that the source tarball for the master-dev image is taken to be the latest source tarball, which is unlikely to be the same commit number as the revision used for the snapshot nix Emacs binary, and thus is likely to cause confusion? Thanks

curl -fsSL https://github.com/emacs-mirror/emacs/tarball/master

[purcell]

I've been doing some work in the last couple of days in order to (hopefully) be able to automatically update the snapshot, perhaps weekly. I now have a scheduled github action which will open an update PR each week, so expect more regular updates in future.

[Silex]

@purcell consider setting the commit SHA1 somewhere so I can reuse it for by my git checkout :wink:

[Silex]

Hi @Silex, I've noticed what that the source tarball for the master-dev image is taken to be the latest source tarball, which is unlikely to be the same commit number as the revision used for the snapshot nix Emacs binary, and thus is likely to cause confusion? Thanks

Yes, good catch.

I need to work on the dev images, they are a bit useless atm. Maybe I'll simply remove them :wink:

[purcell]

consider setting the commit SHA1 somewhere so I can reuse it for by my git checkout

It's in nix/sources.json afaik

[doublep]

This is actually available from Emacs itself normally, and is actually since forever, e.g.:

$ emacs-25 --batch --eval '(print emacs-repository-version)'

"bd299e7629b76c6d4f053dd9c8fb94987f63b460"

However, the Emacs in the images doesn't have this information. Probably it doesn't think during building that its directory is a Git checkout. Looks like a problem with the build process.

[purcell]

Probably it doesn't think during building that its directory is a Git checkout. Looks like a problem with the build process.

I mean, it's not exactly a problem with the build process, but it is connected with it. The builds don't happen from a git repository: archive tarballs are downloaded and unpacked, partly because this is more reproducible (and therefore more standard for Nix). The emacs-repository-version mechanism presumably assumes you're building from a raw git checkout.

In any case, I can definitely figure out how to add this information, it's just that my time is extremely scarce currently, and it's not high on my list of priorities sorry.

[doublep]

If those tarballs are distributed by GNU, you should report a bug. In this case I'd say it's their responsibility to make build process recognize the version, adding whatever hack is necessary and then calling it "official".

Paul

On Fri, 2 Sept 2022 at 10:17, Steve Purcell @.***> wrote:

Probably it doesn't think during building that its directory is a Git checkout. Looks like a problem with the build process.

I mean, it's not exactly a problem with the build process, but it is connected with it. The builds don't happen from a git repository: archive tarballs are downloaded and unpacked, partly because this is more reproducible (and therefore more standard for Nix). The emacs-repository-version mechanism presumably assumes you're building from a raw git checkout.

In any case, I can definitely figure out how to add this information, it's just that my time is extremely scarce currently, and it's not high on my list of priorities sorry.

— Reply to this email directly, view it on GitHub https://github.com/Silex/docker-emacs/issues/86#issuecomment-1235210011, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABYPBO347QQADUA2LI3RVDV4GZ3LANCNFSM5VGB7I5Q . You are receiving this because you commented.Message ID: @.***>

[purcell]

These tarballs are for arbitrary commits and don't contain the version history, so there's no means for the contents of the tarball to determine which commit it came from. There's no shortcoming in the GNU build process, and what they're doing is entirely adequate IMO. What we need is a way to "poke" the commit ID back into the build process, and that's my job. 😄

[doublep]

I still think it's their job. They can add sth. like file forced-repository-version in their tarballs and make sure that the build process (Makefile or whatever determines the version) knows how to use it if present. Then everyone using these tarballs can benefit automatically. Otherwise, if we consider it your job, then you and all others who build from these tarballs need to do this independently, sort of needlessly doing the same thing.

It's actually in their interest, so they get commit hash with bug reports also from those who use the tarballs to build their binaries.

On Fri, 2 Sept 2022 at 10:55, Steve Purcell @.***> wrote:

These tarballs are for arbitrary commits and don't contain the version history, so there's no means for the contents of the tarball to determine which commit it came from. There's no shortcoming in the GNU build process, and what they're doing is entirely adequate IMO. What we need is a way to "poke" the commit ID back into the build process, and that's my job. 😄

— Reply to this email directly, view it on GitHub https://github.com/Silex/docker-emacs/issues/86#issuecomment-1235246295, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABYPBMPTF4V233QJUV56H3V4G6GVANCNFSM5VGB7I5Q . You are receiving this because you commented.Message ID: @.***>

[purcell]

I think your picture of how the process works is skewed. They commit changes to the repo, which results in that commit having a label. There is no build process on their side which results in a commit label or produces a corresponding tarball — the tarball is just a raw export of the git tree as of a particular commit.

[doublep]

There is no build process on their side

Sure, it would be on your side, but would use that file if present. This they can do because they create the Makefile or its sources.

the tarball is just a raw export of the git tree as of a particular commit

Is it that much of a problem that they inject one file into the tarball, with commit hash, before making it available on their server for download? Paul

On Fri, 2 Sept 2022 at 13:03, Steve Purcell @.***> wrote:

I think your picture of how the process works is skewed. They commit changes to the repo, which results in that commit having a label. There is no build process on their side which results in a commit label or produces a corresponding tarball — the tarball is just a raw export of the git tree as of a particular commit.

— Reply to this email directly, view it on GitHub https://github.com/Silex/docker-emacs/issues/86#issuecomment-1235363958, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABYPBJFZFNXO6DKP6KGBLLV4HNHJANCNFSM5VGB7I5Q . You are receiving this because you commented.Message ID: @.***>

[Silex]

Closing due to inactivity.