Re: [PATCH] maint: Update to latest gnulib

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/02/2018 07:09 AM, John Ferlan wrote:
> 
> 
> On 01/02/2018 04:28 AM, Michal Privoznik wrote:
>> Unfortunately, since gnulib's commit of 2c5d558745 there's an
>> unused parameter to stat_time_normalize() function which gnulib
>> developers don't want to fix [1]. Therefore, we have to work
>> around it by temporarily suspending -Wunused-parameter.
>>
>> 1: http://lists.gnu.org/archive/html/bug-gnulib/2018-01/msg00000.html
>>
>> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
>> ---
>>
>> While we have 'gnulib update free' push rule, this one is not trivial at
>> all and thus I have not pushed it. It's ugly and I don't like it. So any
>> ideas are welcome.
>>
>>  .gnulib                    | 2 +-
>>  bootstrap                  | 4 ++--
>>  src/storage/storage_util.c | 3 +++
>>  3 files changed, 6 insertions(+), 3 deletions(-)
>>
> 
> 
> No bright ideas on this other than perhaps only including changes just
> prior to the particular one that breaks things or somehow revert just
> that one in our local copy.

We can provide a downstream-only patch against the gnulib file that adds
the attribute unused marker in our builds, since upstream didn't like
the patch. I'll work up something like that in a moment...

> 
> Other thoughts require additional local changes just to "work around"
> the broken definition.  Such as grabbing the "old" stat-time.h, rename
> it, save it in libvirt sources, then use that new name instead of the
> new .gnulib file. That's probably worse than what you've done though.
> 
> At this point, I think your solution to minimize the impact to one
> include file is perhaps the easiest/best solution albeit not perfect.

Yes, the #pragma usage is more concise than carrying a downstream gnulib
patch, but the two approaches are not that much different in
maintenance, so it will be a matter of taste which variant of the patch
to use.

> 
> It's interesting that there is no desire to fix this problem in .gnulib
> especially since there are already 2 patches proposed and in reality the
> change fundamentally breaks on every platform other than __sun when
> STAT_TIMESPEC is defined just because it's possible (or more desirable
> in the reviewers feedback) to compile with ignore unused-parameter.

I'm also going to reply in the upstream gnulib thread.  When the warning
is in a .c file, they are justified in not caring.  But when it is in a
.h file, it really does seem like something worth cleaning up in gnulib.

> Wonder what would happen if someone posted a patch to .gnulib to revert
> the change for the reason that it breaks other platforms that don't
> desire to configure in that manner. Perhaps Eric Blake would have some
> thoughts or additional muscle with the .gnulib maintainers.
> 


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux