Summary: | net-dns/avahi-0.6.31-r4 with et_EE locale - ga-record-browser.c:165:26: error: '_ga_signals_marshal_VOID__INT_ENUM_STRING_UINT_UINT_POINTER_INT_INT' undeclared (first use in this function) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Priit Laes (IRC: plaes) <plaes> |
Component: | Current packages | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://git.0pointer.de/?p=avahi.git;a=blob;f=avahi-gobject/Makefile.am;h=02f2b9483b4bbed6a5fa68bf844b50130d888999;hb=HEAD#l79 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | patch for Makefile.in |
Description
Priit Laes (IRC: plaes)
2014-02-18 07:46:46 UTC
This indeed looks like an upstream bug. The problem lies likely in signals-marshal.list rule, that uses [A-Z] range in sed expression, which will be wrong in et_EE. :sigh: Need to be more awake during wrangling. I've just repeated a part of the report. (In reply to Rafał Mużyło from comment #1) > This indeed looks like an upstream bug. > > The problem lies likely in signals-marshal.list rule, that uses [A-Z] range > in sed expression, which will be wrong in et_EE. Okay I suck at locales, but should we *build* under LC_ALL="en_US.utf8" but support all other locales at runtime? Would it be sufficient to add export LC_ALL="en_US.utf8" in the ebuild during build or would this mess up all other locales? (In reply to Anthony Basile from comment #3) > (In reply to Rafał Mużyło from comment #1) > > This indeed looks like an upstream bug. > > > > The problem lies likely in signals-marshal.list rule, that uses [A-Z] range > > in sed expression, which will be wrong in et_EE. > > Okay I suck at locales, but should we *build* under LC_ALL="en_US.utf8" but > support all other locales at runtime? Would it be sufficient to add export > LC_ALL="en_US.utf8" in the ebuild during build or would this mess up all > other locales? Instead of en_US, I would use the 'C' locale, although this is just an workaround. The real fix would be to prefix the sed expression with LC_ALL=C or replace the [A-Z] range with full range of alphabet (ABCD...XYZ). (In reply to Priit Laes (IRC: plaes) from comment #4) > (In reply to Anthony Basile from comment #3) > > (In reply to Rafał Mużyło from comment #1) > > > This indeed looks like an upstream bug. > > > > > > The problem lies likely in signals-marshal.list rule, that uses [A-Z] range > > > in sed expression, which will be wrong in et_EE. > > > > Okay I suck at locales, but should we *build* under LC_ALL="en_US.utf8" but > > support all other locales at runtime? Would it be sufficient to add export > > LC_ALL="en_US.utf8" in the ebuild during build or would this mess up all > > other locales? > > Instead of en_US, I would use the 'C' locale, although this is just an > workaround. The real fix would be to prefix the sed expression with LC_ALL=C > or replace the [A-Z] range with full range of alphabet (ABCD...XYZ). Can someone give me a patch for this? @comment 5: the most simple ? Precede the sed call in that rule for signals-marshal.list with 'LANG=C'. Probably by patching that Makefile.in, otherwise, Makefile.am and eautoreconf. Created attachment 383214 [details, diff]
patch for Makefile.in
Sorry, not fully present yet - somehow missed the previous comment said the same thing.
This should work for Makefile.in.
(In reply to Rafał Mużyło from comment #7) > Created attachment 383214 [details, diff] [details, diff] > patch for Makefile.in > > Sorry, not fully present yet - somehow missed the previous comment said the > same thing. > > This should work for Makefile.in. Thanks, I'll commit this, but why isn't the Makefile inheriting LANG in the first place. This is what's been confusing me all along and I wasn't sure where to put it in the build system. I guess you can't go wrong immediately in front of the offending line. (In reply to Anthony Basile from comment #8) > (In reply to Rafał Mużyło from comment #7) > > Created attachment 383214 [details, diff] [details, diff] [details, diff] > > patch for Makefile.in > > > > Sorry, not fully present yet - somehow missed the previous comment said the > > same thing. > > > > This should work for Makefile.in. > > Thanks, I'll commit this, but why isn't the Makefile inheriting LANG in the > first place. This is what's been confusing me all along and I wasn't sure > where to put it in the build system. I guess you can't go wrong immediately > in front of the offending line. Oh wait I see, it *is* inheriting the locale, which is the reason the regex fails. This is fixed in avahi-0.6.31-r5 which I'm going to stabilze now. ...a few minutes after I've posted that patch, I've realized, that just to be safe (in case LC_COLLATE is set), LC_ALL would be a better choice than LANG, but in most cases it will not matter... Then again, in most cases A-Z will be the proper range, so your pick... (In reply to Rafał Mużyło from comment #11) > ...a few minutes after I've posted that patch, I've realized, that just to > be safe (in case LC_COLLATE is set), LC_ALL would be a better choice than > LANG, but in most cases it will not matter... > Then again, in most cases A-Z will be the proper range, so your pick... If you hit the issue again, reopen the bug report and we'll revisit. We've narrowed it down enough for now I think. I can always switch to LC_ALL on any system where it fails to build without any revbump. (In reply to Anthony Basile from comment #12) > (In reply to Rafał Mużyło from comment #11) > > ...a few minutes after I've posted that patch, I've realized, that just to > > be safe (in case LC_COLLATE is set), LC_ALL would be a better choice than > > LANG, but in most cases it will not matter... > > Then again, in most cases A-Z will be the proper range, so your pick... > > If you hit the issue again, reopen the bug report and we'll revisit. We've > narrowed it down enough for now I think. I can always switch to LC_ALL on > any system where it fails to build without any revbump. Funny, I cannot reopen the bug, but the issue is still there: [snip] Making all in avahi-gobject make[2]: Entering directory '/var/tmp/portage/net-dns/avahi-0.6.31-r5/work/avahi-0.6.31-abi_x86_64.amd64/avahi-gobject' ( cd . && \ sed -n -e 's/.*_ga_signals_marshal_\([A-Z]*__[A-Z_]*\).*/\1/p' \ ga-client.c ga-client.h ga-entry-group.c ga-entry-group.h ga-enums.h ga-error.c ga-error.h ga-record-browser.c ga-record-browser.h ga-service-browser.c ga-service-browser.h ga-service-resolver.c ga-service-resolver.h ) \ | sed -e 's/__/:/' -e 'y/_/,/' | sort -u > signals-marshal.list.tmp && \ if cmp -s signals-marshal.list.tmp signals-marshal.list; then \ rm signals-marshal.list.tmp; \ else \ mv signals-marshal.list.tmp signals-marshal.list; \ fi [/snip] It seems that patch is applied against Makefile.in which gets overwritten by eautoconf run. As comment 6 denotes, I didn't look all that much at the ebuild, so I didn't notice it already used eautoreconf. As such, it's the source place in avahi-gobject/Makefile.am that needs to be patched. (In reply to Rafał Mużyło from comment #14) > As comment 6 denotes, I didn't look all that much at the ebuild, so I didn't > notice it already used eautoreconf. > > As such, it's the source place in avahi-gobject/Makefile.am that needs to be > patched. Patch updated to diff -Naur avahi-0.6.31.orig/avahi-gobject/Makefile.am avahi-0.6.31/avahi-gobject/Makefile.am --- avahi-0.6.31.orig/avahi-gobject/Makefile.am 2010-08-25 20:51:39.007153001 -0400 +++ avahi-0.6.31/avahi-gobject/Makefile.am 2014-09-07 19:00:05.485657990 -0400 @@ -76,7 +76,7 @@ signals-marshal.list: $(CORE_SOURCES) Makefile.am $(AM_V_GEN)( cd $(srcdir) && \ - sed -n -e 's/.*_ga_signals_marshal_\([A-Z]*__[A-Z_]*\).*/\1/p' \ + LC_ALL=C sed -n -e 's/.*_ga_signals_marshal_\([A-Z]*__[A-Z_]*\).*/\1/p' \ $(CORE_SOURCES) ) \ | sed -e 's/__/:/' -e 'y/_/,/' | sort -u > $@.tmp && \ if cmp -s $@.tmp $@; then \ Please test and reopen if this doesn't work. (or ping me in irc if you have trouble reopening.) |