patchutils bitbake recipe

patchutils bitbake recipe

[Chuck Wolber]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

Hi,

I checked the layer index (and google) and I find no references to a
bitbake recipe for patchutils. Was there a conscious decision to not
maintain a recipe for patchutils? Or is this something that simply needs a
maintainer to step up and make it happen?

Thank you,

..Ch:W..

[-- Attachment #2: Type: text/html, Size: 381 bytes --]

Re: [yocto] patchutils bitbake recipe

[Josef Holzmayr]

Howdy!

On Wed, Jan 08, 2020 at 11:30:09AM -0800, Chuck Wolber wrote:
> I checked the layer index (and google) and I find no references to a
> bitbake recipe for patchutils. Was there a conscious decision to not
> maintain a recipe for patchutils? Or is this something that simply needs a
> maintainer to step up and make it happen?

Write a recipe and submit :) I don't think there was ever a "conscious
decision" to not support a specific package for non-technical reasons.
And this one doesn't also look like it has any noteworthy implications -
its autotoolized and GPLv2. So a good one to get involved for sure.

The only thing that *could* theoretically happen, is that if no usecase
other than a very specific one of yours can be seen, that you are asked
to keep it in a layer of your own instead of being accepted into
meta-openembedded (because thats where it would have to go).

Greetz

-- 
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

Re: [yocto] patchutils bitbake recipe

[Chuck Wolber]

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

>
> Write a recipe and submit :) I don't think there was ever a "conscious
> decision" to not support a specific package for non-technical reasons.
> And this one doesn't also look like it has any noteworthy implications -
> its autotoolized and GPLv2. So a good one to get involved for sure.
>

Thanks! It sounds like I am not stepping into an historical tarpit then.
There
are so many references to patchutils in the Yocto ecosystem that I figured
there just had to be some reason for the non-existence of a recipe.

Indeed such a recipe looks fairly simple. I will check the appropriate layer
README for patch submission details.


The only thing that *could* theoretically happen, is that if no usecase
> other than a very specific one of yours can be seen, that you are asked
> to keep it in a layer of your own instead of being accepted into
> meta-openembedded (because thats where it would have to go).
>

Well, while I have your mind on that topic... I spent a great deal of time
building a self hosting/building yocto environment. I started with an
Ubuntu install, built an image that met all of our internal development
needs, and then discarded the Ubuntu install. This development image
inherits from the image that builds the embedded OS we deliver as a
product.

Our developers now work from our Yocto built environment to do their
development. Updates are built within that image and all developers
move on to the next one as needed. This approach ensures that application
development done for our embedded OS is guaranteed to be consistent.
Over the last few years it has resulted in a lot of tangible benefits.

There are many more details, of course (Virtual machines are used, etc),
but that should set the stage.

As we embark on our next version, it occurs to me that Richard Purdie's
excellent combo-layer tool is a better way of managing all of the upstream
repos. As I was experimenting with it, I found that patchutils is nowhere
to be found in the yocto ecosystem.

So... is "building a self-hosting" environment a decent use case? I think
as it becomes easier to do this, it will become de rigeur to work from an
environment like that.

And sorry in advance if I opened any cans of worms :)


Thanks,

..Ch:W..

[-- Attachment #2: Type: text/html, Size: 3083 bytes --]

Re: [yocto] patchutils bitbake recipe

[Josef Holzmayr]

Howdy!

On Wed, Jan 08, 2020 at 01:14:17PM -0800, Chuck Wolber wrote:
> >
> > Write a recipe and submit :) I don't think there was ever a "conscious
> > decision" to not support a specific package for non-technical reasons.
> > And this one doesn't also look like it has any noteworthy implications -
> > its autotoolized and GPLv2. So a good one to get involved for sure.
> >
> 
> Thanks! It sounds like I am not stepping into an historical tarpit then.
> There
> are so many references to patchutils in the Yocto ecosystem that I figured
> there just had to be some reason for the non-existence of a recipe.
> 
> Indeed such a recipe looks fairly simple. I will check the appropriate layer
> README for patch submission details.

Have fun, and feel free to return with arising questions :)

> <snip/>
> 
> So... is "building a self-hosting" environment a decent use case? I think
> as it becomes easier to do this, it will become de rigeur to work from an
> environment like that.

Anything that works for you is a decent usecase. In terms of Yocto/OE,
the line between decent and non-decent is less a technical than a
social one.
Decent: "Hey did this weird stuff, and its just what I need. Thanks!"
Non-Decent: "Hey I want to do this weird stuff but it doesnt work
because XYZ, so its your job to fix ABC in order to please me!"

Read that as: we're mostly in embedded, people do strange stuff all the
time. If what we do is useful for you, go ahead.

And on the topic of self-hosting, we actually have something called
"packagegroup-self-hosted" which should be nice base to build from.

> And sorry in advance if I opened any cans of worms :)

None detected.

Greetz

-- 
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548