All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Bisson <gary.bisson@boundarydevices.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v3 1/1] package/mfgtools: bump to version 1.3.154
Date: Wed, 20 May 2020 14:53:01 +0200	[thread overview]
Message-ID: <20200520125301.GA1380486@p1g2> (raw)
In-Reply-To: <20200413214249.206017-1-joerg.krause@embedded.rocks>

Hi Jorg,

On Mon, Apr 13, 2020 at 11:42:49PM +0200, J?rg Krause wrote:
> The version 0.02 was a pre-release and is dated from Nov 20, 2017.
> 
> Meanwhile:
>  * the repo owner switch to NXPmicro
>  * latest version is 1.3.154
>  * the build system is CMake
>  * the license is BSD-3 only
>  * update the license hash as the copyright year and the owner has
>    changed
>  * drop the readme.txt file as is outdated
>  * drop patch, which is not needed with the new version
>  * update dependencies
> 
> Note, that mfgtools uses git to define a version string `GIT_VERSION`.
> It does so even when building from a source tarball (automatically
> generated by github). The problem is, that git provides the version
> information of Buildroot and mfgtools uses this version information to
> do a runtime check to detect outdated command list scripts.

Actually in latest release, the tarball generated includes a
.tarball-version file that includes the proper revision.
It is supported since 1.3.169, which is considered "pre-release" as it
isn't used in a GA BSP yet, but I think that feature is interesting
enough to bump the package already.

> We use a hook which the version generation script provides to write the
> correct version string.
> 
> Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> ---
> v3:
>  * bump to latest version 1.3.154
>  * adapt version string hook to changes done upstream
>  * add optional host OpenSSL dependency to add support for https
>    download (introduced in 1.3.102)

I'm confused I thought we agreed that it'd be best to keep mgftools
as-is and only create a new "uuu" or "imx-uuu" package not to break
compatibility with people using the mfgtools v2? [1]
Has there been a new development in that discussion?

Regards,
Gary

[1] http://patchwork.ozlabs.org/project/buildroot/patch/20200109191020.1282319-2-joerg.krause at embedded.rocks/

  parent reply	other threads:[~2020-05-20 12:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 21:42 [Buildroot] [PATCH v3 1/1] package/mfgtools: bump to version 1.3.154 Jörg Krause
2020-05-19 21:08 ` Thomas Petazzoni
2020-05-19 21:23   ` Thomas Petazzoni
2020-05-20 12:53 ` Gary Bisson [this message]
2020-05-25  8:11   ` Jörg Krause

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200520125301.GA1380486@p1g2 \
    --to=gary.bisson@boundarydevices.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.