[Buildroot] [PATCH v2 2/2] package/localedef: bump to version 2.34-9-g9acab0bba6a5a57323b1f94bf95b21618a9e5aa4

Arnout Vandecappelle arnout at mind.be
Thu Aug 26 21:55:08 UTC 2021



On 22/08/2021 21:22, Petr Vorel wrote:
> Hi Romain,
> 
>> Hello Petr,
> 
>> Le 22/08/2021 à 21:02, Petr Vorel a écrit :
>>> resync the version with glibc package.
> 
>>> Dropped 2 patches (fixes backported from previous releases),
>>> rebased 2 which are kept (only line numbers changed).
> 
>>> Suggested-by: Romain Naour <romain.naour at gmail.com>
>>> Signed-off-by: Petr Vorel <petr.vorel at gmail.com>
> 
>> Thanks for this new version.
> 
>> But it will conflict with my patch that resync the glibc version for 2.33

 Resolving those conflicts isn't too difficult, so don't worry about it.

 Well, actually, the "refresh" of the patches *does* make it a bit difficult.
It's nicer for us if you leave patches untouched as long as they still apply
correctly.

> 
>> http://patchwork.ozlabs.org/project/buildroot/patch/20210821131256.1138002-1-romain.naour@gmail.com/
> OK, I'll rebase it once your commit gets merged.
> But if bump considered safe, maybe my commits could be taken as it is.

 That's what I did :-)

> 
>> Since glibc and localedef are really the same project, I would suggest to bump
>> the version with one commit.
> 
>> I agree, It's not convenient to take care of localedef package at the same time
>> of glibc.
> I was thinking about it as well, but when packages are independent it's IMHO
> slightly better to split it.

 I don't care much either way - there are arguments for both options. localedef
and glibc aren't tied that strictly, it's just that glibc changes may result in
different output of localedef, which you won't notice until you actually use
those locales at runtime (and then only if you used the changed aspect of it).
So it's more a just-to-be-safe thing.

 Regards,
 Arnout

> 
> Kind regards,
> Petr
> 
>> Best regards,
>> Romain
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


More information about the buildroot mailing list