Bug 247099 - editors/micro: Update to 2.0.4
Summary: editors/micro: Update to 2.0.4
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Steve Wills
URL:
Keywords: buildisok, needs-patch
Depends on:
Blocks:
 
Reported: 2020-06-08 22:47 UTC by rlwestlund
Modified: 2020-06-25 03:24 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (swills)


Attachments
patch (13.88 KB, patch)
2020-06-09 08:47 UTC, Mikael Urankar
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description rlwestlund 2020-06-08 22:47:20 UTC
The editors/micro port is still on 1.4.1, while 2.0.4 is released. I tried to make the necessary Makefile changes myself but gave up; I'm a novice at porting and there are some difficulties involved with this change. This Github issue provides some background: https://github.com/zyedidia/micro/issues/1711

The project uses gmake internally, and its Makefile requires being in the Git repository to determine version information. Currently, the port seems to work by ignoring the project's Makefile and doing the build itself, inserting the -ldflags, but I don't believe this is the right approach. It would require duplicating code between the two Makefiles (and also the port Makefile currently hardcodes the build date as August 9 2018, which is silly - the project's Makefile runs a Go script that determines the actual date).

I couldn't make a patch myself because I couldn't figure out how to make it clone the repository instead of just downloading an archive.
Comment 1 Mikael Urankar freebsd_committer 2020-06-09 08:47:43 UTC
Created attachment 215386 [details]
patch
Comment 2 rlwestlund 2020-06-09 14:27:30 UTC
That patch still ignores the project's makefile and hardcodes a build date. I'm sure build date is less important than version, but is there no way to let the project's own stuff handle this?
Comment 3 Mikael Urankar freebsd_committer 2020-06-09 15:10:14 UTC
(In reply to rlwestlund from comment #2)
Why?
Comment 4 rlwestlund 2020-06-09 16:04:57 UTC
I think I explained my thinking in the first comment and the linked issue. It seems to me like duplicating code between the port and the project is something we should avoid if we can. Especially since the hardcoded build date will be wrong; is that not worse than just leaving it blank?
Comment 5 Tobias Kortkamp freebsd_committer 2020-06-09 16:12:26 UTC
(In reply to rlwestlund from comment #4)
> Especially since the hardcoded build date will be wrong; is that not worse than just leaving it blank?

Compiling in the actual build date instead of a fixed date is a
source of non-reproducibility [1] that is best avoided if possible.

[1] https://reproducible-builds.org/docs/timestamps/
Comment 6 Mikael Urankar freebsd_committer 2020-06-09 16:22:23 UTC
(In reply to rlwestlund from comment #4)
I don't understand why you are so focused on the build date, what is a correct build date for you? The hardcoded build date is the date of the release, is it better than the date of the build (which will change quite often on FreeBSD)?

We'll have to patch the project Makefile if we want to use it...:
===>  Building micro from .
can't load package: package .: no Go files in /usr/ports/editors/micro/work/micro-2.0.4
*** Error code 1
Comment 7 rlwestlund 2020-06-09 16:43:48 UTC
I didn't consider that true build dates are a source of unreproduceability. That's a good point.

> I don't understand why you are so focused on the build date, what is a correct build date for you? The hardcoded build date is the date of the release, is it better than the date of the build (which will change quite often on FreeBSD)?

My thinking was that the build date should be the date on which it was built. Including the date of release and calling it build date is just misleading.

However, I've been more or less that the build date is not something that belongs compiled in, and doing it this way does allow the port to build without gmake and git as build dependencies.

Though it is possible to compile it this way and include the proper version and commit hash without including build date. It prints as "Unknown" with `micro -version`. Unless it's a custom I'm not aware of that "build date" actually means release date, (which doesn't seem so because the project's makefile includes the actual build date,) wouldn't that be preferable to having `micro -version` output "Compiled on..." a date it wasn't compiled on?
Comment 8 Automation User 2020-06-24 00:08:55 UTC
Build info is available at https://gitlab.com/swills/freebsd-ports/pipelines/159423158
Comment 9 rlwestlund 2020-06-25 00:04:29 UTC
Well, in the time this has taken, Micro version 2.0.6 has been tagged.
Comment 10 commit-hook freebsd_committer 2020-06-25 03:23:17 UTC
A commit references this bug:

Author: swills
Date: Thu Jun 25 03:23:07 UTC 2020
New revision: 540361
URL: https://svnweb.freebsd.org/changeset/ports/540361

Log:
  editors/micro: update to 2.0.4

  PR:		247099
  Submitted by:	rlwestlund@gmail.com

Changes:
  head/editors/micro/Makefile
  head/editors/micro/distinfo
Comment 11 Steve Wills freebsd_committer 2020-06-25 03:24:06 UTC
Sorry it took so long, went ahead and committed it as-is. I'll try to do the update to 2.0.5 more quickly if someone sends a patch. Thanks!