sunxi-tools: tagging a new release?

[Karsten Merker]

Hello everybody,

AFAICS the sunxi-tools "fel" utility rework is complete now, so
how about tagging a new sunxi-tools upstream release (v1.3)? I
think that would make sense as the "fel" rework is a major step
and having an "official" upstream release makes things nicer for
distribution packagers.

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[Ian Campbell]

(adding some CCs of people who I think might be in a position to do
this)

On Tue, 2015-10-06 at 21:13 +0200, Karsten Merker wrote:
> Hello everybody,
>
> AFAICS the sunxi-tools "fel" utility rework is complete now, so
> how about tagging a new sunxi-tools upstream release (v1.3)? I
> think that would make sense as the "fel" rework is a major step
> and having an "official" upstream release makes things nicer for
> distribution packagers.

Yes please. While I can package a snapshot I'd much rather package an
actual release.

For my part that just means a tag, no need for tarballs etc.

Ian.

[Benjamin Henrion]

Tarballs are better, as most package managers do not have GIT
integration (deb, rpm, etc...).

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

[Ian Campbell]

On Sun, 2015-10-11 at 12:10 +0200, Benjamin Henrion wrote:
> On Sun, Oct 11, 2015 at 11:54 AM, Ian Campbell <i...@hellion.org.uk> wrote:
> > (adding some CCs of people who I think might be in a position to do
> > this)
> >
> > On Tue, 2015-10-06 at 21:13 +0200, Karsten Merker wrote:
> >> Hello everybody,
> >>
> >> AFAICS the sunxi-tools "fel" utility rework is complete now, so
> >> how about tagging a new sunxi-tools upstream release (v1.3)? I
> >> think that would make sense as the "fel" rework is a major step
> >> and having an "official" upstream release makes things nicer for
> >> distribution packagers.
> >
> > Yes please. While I can package a snapshot I'd much rather package an
> > actual release.
> >
> > For my part that just means a tag, no need for tarballs etc.
>
> Tarballs are better, as most package managers do not have GIT
> integration (deb, rpm, etc...).

Perhaps, but like I said, I don't need them for my purposes (Debian
packaging).

Ian.

[Siarhei Siamashka]

On Sun, 11 Oct 2015 10:54:32 +0100
Ian Campbell <i...@hellion.org.uk> wrote:

> (adding some CCs of people who I think might be in a position to do
> this)
>
> On Tue, 2015-10-06 at 21:13 +0200, Karsten Merker wrote:
> > Hello everybody,
> >
> > AFAICS the sunxi-tools "fel" utility rework is complete now, so
> > how about tagging a new sunxi-tools upstream release (v1.3)? I
> > think that would make sense as the "fel" rework is a major step
> > and having an "official" upstream release makes things nicer for
> > distribution packagers.
>
> Yes please. While I can package a snapshot I'd much rather package an
> actual release.

Yes, a new tag can be easily created at any time.

There is still an unresolved inconvenience related to Linux
distributions arbitrarily renaming the tools when doing sunxi-tools
packaging. It would be great if we could have a unification of the
tool names just for the sake of ensuring that the documentation and
howto guides can be easily used without confusing the users.

If we had a sunxi-tools maintainer, then that person could also
make a release announcement with the list of changes since the
previous tag.

> For my part that just means a tag, no need for tarballs etc.

This is a non-issue because github automatically generates tarballs
for the release tags.

--
Best regards,
Siarhei Siamashka

[Ian Campbell]

On Sun, 2015-10-11 at 13:36 +0300, Siarhei Siamashka wrote:
> On Sun, 11 Oct 2015 10:54:32 +0100
> Ian Campbell <i...@hellion.org.uk> wrote:
>
> > (adding some CCs of people who I think might be in a position to do
> > this)
> >
> > On Tue, 2015-10-06 at 21:13 +0200, Karsten Merker wrote:
> > > Hello everybody,
> > >
> > > AFAICS the sunxi-tools "fel" utility rework is complete now, so
> > > how about tagging a new sunxi-tools upstream release (v1.3)? I
> > > think that would make sense as the "fel" rework is a major step
> > > and having an "official" upstream release makes things nicer for
> > > distribution packagers.
> >
> > Yes please. While I can package a snapshot I'd much rather package
> an
> > actual release.
>
> Yes, a new tag can be easily created at any time.
>
> There is still an unresolved inconvenience related to Linux
> distributions arbitrarily renaming the tools when doing sunxi-tools
> packaging. It would be great if we could have a unification of the
> tool names just for the sake of ensuring that the documentation and
> howto guides can be easily used without confusing the users.

The Debian package (of v1.2-ish) has:
install -m0755 usb-boot $(PKG)/usr/bin/sunxi-usb-boot
install -m0755 fel $(PKG)/usr/bin/sunxi-fel
install -m0755 fexc $(PKG)/usr/bin/sunxi-fexc
install -m0755 bootinfo $(PKG)/usr/bin/sunxi-bootinfo

I'd be happy to put that together as a patch for upstream instead.

The current packaging does not install nand-part, fel-pio, jtag-loop,
fel-sdboot or boot_head for various reasons (which I'd want to revisit
with v1.3). I'd be inclined to prefix them all with "sunxi-" too if I
were to install them.

> If we had a sunxi-tools maintainer, then that person could also
> make a release announcement with the list of changes since the
> previous tag.
>
> > For my part that just means a tag, no need for tarballs etc.
>
> This is a non-issue because github automatically generates tarballs
> for the release tags.

Great!

Ian.

[Peter Korsgaard]

>>>>> "Ian" == Ian Campbell <i...@hellion.org.uk> writes:

Hi,

> The Debian package (of v1.2-ish) has:
> install -m0755 usb-boot $(PKG)/usr/bin/sunxi-usb-boot
> install -m0755 fel $(PKG)/usr/bin/sunxi-fel
> install -m0755 fexc $(PKG)/usr/bin/sunxi-fexc
> install -m0755 bootinfo $(PKG)/usr/bin/sunxi-bootinfo

> I'd be happy to put that together as a patch for upstream instead.

FYI, in Buildroot we currently install fexc bin2fex fex2bin bootinfo fel
pio for the host and nand-part for the target, all without any prefix.

--
Bye, Peter Korsgaard

[Ian Campbell]

Would you have an issue with the upstream names changing? Or would you
just follow along?

Ian.

[Ian Campbell]

On Sun, 2015-10-11 at 12:06 +0100, Ian Campbell wrote:
> [...]

> > There is still an unresolved inconvenience related to Linux
> > distributions arbitrarily renaming the tools when doing sunxi-tools
> > packaging. It would be great if we could have a unification of the
> > tool names just for the sake of ensuring that the documentation and
> > howto guides can be easily used without confusing the users.
>
> The Debian package (of v1.2-ish) has:
> install -m0755 usb-boot $(PKG)/usr/bin/sunxi-usb-boot
> install -m0755 fel $(PKG)/usr/bin/sunxi-fel
> install -m0755 fexc $(PKG)/usr/bin/sunxi-fexc
> install -m0755 bootinfo $(PKG)/usr/bin/sunxi-bootinfo
>
> I'd be happy to put that together as a patch for upstream instead.

If we do want to do this then there's a few choices to make:

Which tools to prefix with "sunxi-" and which to not. I'd be inclined
to prefix most of them except but keep fex2bin bin2fex as they are.

Renaming the source files vs. having the Makefile e.g. build fel.c into
a sunxi-fel binary. Makefile has a mixture of explicit rules and a
implicit (%: %.c) one.

Shall we add an install target to the Makefile or not. If yes then
which tools is useful to add to the install target.

I would rule out having the install target perform the rename, since I
think it is not uncommon for instructions etc to involve running the
tools right out of the build tree, so having those use different names
to what is installed would be v. confusing.

I'd be inclined to:
* Prefix everything except bin2fex+fex2bin with sunxi-
* Try doing the rename via Makefile runes to start with but consider
renaming if the Makefile gets too ugly
* Add an install rule starting with just the 4 mentioned above. Others
can be added later.

In the absence of any objections I'll knock up a patch one evening this
week.

Ian.

[Peter Korsgaard]

>>>>> "Ian" == Ian Campbell <i...@hellion.org.uk> writes:

Hi,

>> > I'd be happy to put that together as a patch for upstream instead.
>>
>> FYI, in Buildroot we currently install fexc bin2fex fex2bin bootinfo fel
>> pio for the host and nand-part for the target, all without any prefix.

> Would you have an issue with the upstream names changing? Or would you
> just follow along?

No, we don't really mind. We just try to follow upstream.

--
Bye, Peter Korsgaard

[Peter Korsgaard]

>>>>> "Ian" == Ian Campbell <i...@hellion.org.uk> writes:

Hi,

> I'd be inclined to:
> * Prefix everything except bin2fex+fex2bin with sunxi-
> * Try doing the rename via Makefile runes to start with but consider
> renaming if the Makefile gets too ugly
> * Add an install rule starting with just the 4 mentioned above. Others
> can be added later.

Sounds sensible to me. Please make sure the install rule respects
DESTDIR.

--
Bye, Peter Korsgaard

[Siarhei Siamashka]

Thanks! That's a move in the right direction.

BTW, Fedora is also doing sunxi-tools renaming (at least for bootinfo
and usb-boot according to their changelog):
http://pkgs.fedoraproject.org/cgit/sunxi-tools.git/commit/?id=278562dda1c13c7ae1b466a7f938933dff7bf0ce

Hence I also added Lubomir Rintel to CC. It would be great to ensure
that at least Fedora and Debian maintainers come to an agreement about
their tools naming preferences.


IMHO it's best to do this renaming right now. So that it comes together
with user visible features, which exist in the current sunxi-tools git
repository. At least there would be an incentive for the users to
upgrade to the upcoming sunxi-tools release and thus finally put an
end to this tool names mismatch chaos.

[Ian Campbell]

On Tue, 2015-10-13 at 11:42 +0300, Siarhei Siamashka wrote:
> IMHO it's best to do this renaming right now.

I agree, lets get this squared away now and then do the v1.3 release
afterwards (but, hopefully, soon).

Ian.

[Ian Campbell]

Absolutely!

I was intending:

DESTDIR ?=
PREFIX ?= /usr/local

Then install to $(DESTDIR)$(prefix)/bin. Packages would then most likely
want to use DESTDIR=/some/pkgbuild/scratch/area PREFIX=/usr.

Ian.

[Peter Korsgaard]

>>>>> "Ian" == Ian Campbell <i...@hellion.org.uk> writes:

Hi,

>> Sounds sensible to me. Please make sure the install rule respects
>> DESTDIR.

> Absolutely!

> I was intending:

> DESTDIR ?=
> PREFIX ?= /usr/local

> Then install to $(DESTDIR)$(prefix)/bin. Packages would then most likely
> want to use DESTDIR=/some/pkgbuild/scratch/area PREFIX=/usr.

Indeed, thanks!

--
Venlig hilsen,
Peter Korsgaard

[Ian Campbell]

On Sun, 2015-10-11 at 21:11 +0200, Peter Korsgaard wrote:

FWIW I came to the opposite conclusion wrt pio and nand-part while
hacking on the Makefile just now.

pio requires access to /dev/mem and pokes at the real hardware pio,
hence is only useful on the target.

nand-part (looks like it) can operate on NAND file images as well as
/dev/nand and hence is potentially useful on both host and target.

Have I misunderstood something? (I'm about to send out some patches
based on this, so if so I'll have to iterate).

Ian.

[Peter Korsgaard]

>>>>> "Ian" == Ian Campbell <i...@hellion.org.uk> writes:

Hi,

>> FYI, in Buildroot we currently install fexc bin2fex fex2bin bootinfo fel
>> pio for the host and nand-part for the target, all without any prefix.

> FWIW I came to the opposite conclusion wrt pio and nand-part while
> hacking on the Makefile just now.

> pio requires access to /dev/mem and pokes at the real hardware pio,
> hence is only useful on the target.

> nand-part (looks like it) can operate on NAND file images as well as
> /dev/nand and hence is potentially useful on both host and target.

> Have I misunderstood something? (I'm about to send out some patches
> based on this, so if so I'll have to iterate).

No, it sounds sensible. I didn't do the sunxi-tools integration (and
until recently I didn't have any sunxi hw). I'll adjust the Buildroot
package to match - Thanks.

--
Bye, Peter Korsgaard