ipmitool recipe update needed?

ipmitool recipe update needed?

[Andrew Geissler]

Hi Alexander,

A while back we had some intermittent CI failures when
trying to retrieve the ipmitool package from sourceforge.

The link for ipmitool on sourceforge shows it's been moved
to github. Are there plans to update the recipe upstream to
use github? William noted in the infrastructure workgroup that
you'll probably have to provide the package in the expected
format on github for it to work.

The recipe is:
meta-openembedded/meta-oe/recipes-kernel/ipmitool/ipmitool_1.8.18.bb

Andrew

Re: ipmitool recipe update needed?

[Alexander Amelkin]

[-- Attachment #1.1: Type: text/plain, Size: 1021 bytes --]

Hi, Andrew!

Yes, I've seen that recipe and planned to update it, just didn't have time to. You may do so yourself if you want.

Releases are automatically packaged by GitHub according to tags and the tags in the project are like IPMITOOL_1_8_18, so the packaged release is https://github.com/ipmitool/ipmitool/archive/IPMITOOL_1_8_18.tar.gz

For future releases I planned to continue using the same tagging scheme.

Alexander.

09.04.2019 19:02, Andrew Geissler wrote:
> Hi Alexander,
>
> A while back we had some intermittent CI failures when
> trying to retrieve the ipmitool package from sourceforge.
>
> The link for ipmitool on sourceforge shows it's been moved
> to github. Are there plans to update the recipe upstream to
> use github? William noted in the infrastructure workgroup that
> you'll probably have to provide the package in the expected
> format on github for it to work.
>
> The recipe is:
> meta-openembedded/meta-oe/recipes-kernel/ipmitool/ipmitool_1.8.18.bb
>
> Andrew


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: ipmitool recipe update needed?

[William Kennington]

The problem with the archive tarballs is that their contents are not
stable (they are autogenerated when needed from git), and they aren't
dist tarballs so they haven't been run over `./bootstrap.sh;
./configure; make dist` yet.

On Thu, Apr 11, 2019 at 4:08 AM Alexander Amelkin <a.amelkin@yadro.com> wrote:
>
> Hi, Andrew!
>
> Yes, I've seen that recipe and planned to update it, just didn't have time to. You may do so yourself if you want.
>
> Releases are automatically packaged by GitHub according to tags and the tags in the project are like IPMITOOL_1_8_18, so the packaged release is https://github.com/ipmitool/ipmitool/archive/IPMITOOL_1_8_18.tar.gz
>
> For future releases I planned to continue using the same tagging scheme.
>
> Alexander.
>
> 09.04.2019 19:02, Andrew Geissler wrote:
> > Hi Alexander,
> >
> > A while back we had some intermittent CI failures when
> > trying to retrieve the ipmitool package from sourceforge.
> >
> > The link for ipmitool on sourceforge shows it's been moved
> > to github. Are there plans to update the recipe upstream to
> > use github? William noted in the infrastructure workgroup that
> > you'll probably have to provide the package in the expected
> > format on github for it to work.
> >
> > The recipe is:
> > meta-openembedded/meta-oe/recipes-kernel/ipmitool/ipmitool_1.8.18.bb
> >
> > Andrew
>

Re: ipmitool recipe update needed?

[Vernon Mauery]

On 11-Apr-2019 02:08 PM, Alexander Amelkin wrote:
>Hi, Andrew!
>
>Yes, I've seen that recipe and planned to update it, just didn't have time to. You may do so yourself if you want.
>
>Releases are automatically packaged by GitHub according to tags and the tags in the project are like IPMITOOL_1_8_18, so the packaged release is https://github.com/ipmitool/ipmitool/archive/IPMITOOL_1_8_18.tar.gz
>
>For future releases I planned to continue using the same tagging scheme.

Would it be better to just point at the upstream release tag instead of 
the release tarball?

Along these lines, if we can get my pending dbus interface pull-request 
merged, openbmc can use the upstream ipmitool with only one patch to 
change the default interface (which is on my list to make a --configure 
option at some point).

--Vernon

>Alexander.
>
>09.04.2019 19:02, Andrew Geissler wrote:
>> Hi Alexander,
>>
>> A while back we had some intermittent CI failures when
>> trying to retrieve the ipmitool package from sourceforge.
>>
>> The link for ipmitool on sourceforge shows it's been moved
>> to github. Are there plans to update the recipe upstream to
>> use github? William noted in the infrastructure workgroup that
>> you'll probably have to provide the package in the expected
>> format on github for it to work.
>>
>> The recipe is:
>> meta-openembedded/meta-oe/recipes-kernel/ipmitool/ipmitool_1.8.18.bb
>>
>> Andrew
>

Re: ipmitool recipe update needed?

[Alexander Amelkin]

[-- Attachment #1.1: Type: text/plain, Size: 560 bytes --]

11.04.2019 22:49, Vernon Mauery wrote:
>
> Would it be better to just point at the upstream release tag instead of the release tarball?

Indeed that could be the right approach for petitboot.

>
> Along these lines, if we can get my pending dbus interface pull-request merged, openbmc can use the upstream ipmitool with only one patch to change the default interface (which is on my list to make a --configure option at some point).
>
Both your patches are now merged, so no patches on the buildroot side are needed if git is used.

Alexander.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: ipmitool recipe update needed?

[Alexander Amelkin]

[-- Attachment #1.1: Type: text/plain, Size: 1041 bytes --]

11.04.2019 22:07, William Kennington wrote:
> The problem with the archive tarballs is that their contents are not
> stable (they are autogenerated when needed from git), and they aren't
> dist tarballs so they haven't been run over `./bootstrap.sh;
> ./configure; make dist` yet.

Well, they are stable enough because they are autogenerated from the same git hash each time.

As to not being 'dist' tarballs, is that actually a problem (at least for op-build) ?
Release tarballs on sourceforge haven't been run through bootstrap and configure as well, because that's useless.
You would need to re-run it on your target build system anyway.

As Vernon suggested, using git instead of tarballs would be even better. The code in the repository has been significantly improved since 1.8.18 already, yet I don't feel so far like tagging a new release. Nonetheless, I don't see why the top of trunk couldn't be used for op-build.

With best regards,
Alexander Amelkin,
Leading BMC Software Engineer, YADRO
https://yadro.com



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: ipmitool recipe update needed?

[Vernon Mauery]

On 16-Apr-2019 04:27 PM, Alexander Amelkin wrote:
>11.04.2019 22:07, William Kennington wrote:
>> The problem with the archive tarballs is that their contents are not
>> stable (they are autogenerated when needed from git), and they aren't
>> dist tarballs so they haven't been run over `./bootstrap.sh;
>> ./configure; make dist` yet.
>
>Well, they are stable enough because they are autogenerated from the same git hash each time.
>
>As to not being 'dist' tarballs, is that actually a problem (at least for op-build) ?
>Release tarballs on sourceforge haven't been run through bootstrap and configure as well, because that's useless.
>You would need to re-run it on your target build system anyway.
>
>As Vernon suggested, using git instead of tarballs would be even better. The code in the repository has been significantly improved since 1.8.18 already, yet I don't feel so far like tagging a new release. Nonetheless, I don't see why the top of trunk couldn't be used for op-build.

I have pushed a patch to meta-oe that just uses a recent hash from the 
upstream git. Ideally, it would go tag to tag or something like that. I 
am not sure about the tagging or release schedule for ipmitool.

--Vernon