| Summary: | games-board/kwappen-1.1.5: fails to build with parser error (same as Bug 206370) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jabari R. Roberts <tECHIDNA> |
| Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Build log
EBuild environment file Modified ebuild, with sed accounting for octal notation in the regexp script |
||
|
Description
Jabari R. Roberts
2008-03-31 01:08:27 UTC
Created attachment 147760 [details]
Build log
Created attachment 147761 [details]
EBuild environment file
head -n 122 index.docbook | tail -n 1 <title>Opï¿es</title> Should look like that in the /var/tmp/portage/games-board/kwappen-1.1.5/work/kwappen-1.1.5/doc/pt directory. Does it? (In reply to comment #3) > head -n 122 index.docbook | tail -n 1 > <title>Opï¿es</title> > > Should look like that in the > /var/tmp/portage/games-board/kwappen-1.1.5/work/kwappen-1.1.5/doc/pt directory. > Does it? > Unfortunately, no; it gives the same Unicode "Unknown character" symbol in any application I tried. Output from Konsole: **************** Chaos-X3 ~ # cd /var/tmp/portage/games-board/kwappen-1.1.5/work/kwappen-1.1.5/doc/pt Chaos-X3 pt # head -n 122 index.docbook | tail -n 1 <title>Op��es</title> Chaos-X3 pt # **************** Output from XTerm (yes, it's the same as Konsole, but just checking to make sure it wasn't my term charset I setup in KDE): **************** Chaos-X3 ~ # cd /var/tmp/portage/games-board/kwappen-1.1.5/work/kwappen-1.1.5/doc/pt Chaos-X3 pt # head -n 122 index.docbook | tail -n 1 <title>Op��es</title> Chaos-X3 pt # **************** Output from the area around line 122 from vim: **************** </sect1> </chapter> <chapter id="options"> <title>Op<8d><9b>es</title> <sect1 id="autoshrink"> <title>Tempo da autoredução</title> <para> **************** Output from the area around line 122 from KWrite (note that KWrite can translate the Portuguese characters correctly): **************** </sect1> </chapter> <chapter id="options"> <title>Op��es</title> <sect1 id="autoshrink"> <title>Tempo da autoredução</title> <para> **************** So it seems to be a problem in the source tarball (i.e. a problem from upstream)? What's the output from: head -n 3 kwappen-1.1.5.ebuild (In reply to comment #5) > What's the output from: > > head -n 3 kwappen-1.1.5.ebuild > Chaos-X3 ~ # cd /usr/portage/games-board/kwappen/ Chaos-X3 kwappen # head -n 3 kwappen-1.1.5.ebuild # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/games-board/kwappen/kwappen-1.1.5.ebuild,v 1.3 2008/01/28 01:55:34 mr_bones_ Exp $ Chaos-X3 kwappen # After you unpack it, what's the output from: grep "title>Op" index.docbook | od -cN14 in the pt directory? (In reply to comment #7) > After you unpack it, what's the output from: > > grep "title>Op" index.docbook | od -cN14 > > in the pt directory? knuckles@Chaos-X3 ~ $ tar -xzf /usr/portage/distfiles/kwappen-1.1.5.tar.gz -C tmp/ knuckles@Chaos-X3 ~ $ cd tmp/kwappen-1.1.5/doc/pt knuckles@Chaos-X3 ~/tmp/kwappen-1.1.5/doc/pt $ grep "title>Op" index.docbook | od -cN14 0000000 < t i t l e > O p 215 233 e s < 0000016 knuckles@Chaos-X3 ~/tmp/kwappen-1.1.5/doc/pt $ Just in case you were about to ask ;-)... knuckles@Chaos-X3 ~ $ sha1sum /usr/portage/distfiles/kwappen-1.1.5.tar.gz a07208d0a9a011ec5cf64a93b2d07f7e2775d220 /usr/portage/distfiles/kwappen-1.1.5.tar.gz knuckles@Chaos-X3 ~ $ grep a07208d0a9a011ec5cf64a93b2d07f7e2775d220 /usr/portage/games-board/kwappen/Manifest DIST kwappen-1.1.5.tar.gz 1138413 RMD160 6ce9e0a9cf6a1999a7f91e2355c89b039ff9d114 SHA1 a07208d0a9a011ec5cf64a93b2d07f7e2775d220 SHA256 42e2d8677704f1c0b7b489afc50e5ffdb5c747cfa24aa28bfcaecc65ae6c9679 knuckles@Chaos-X3 ~ $ No, do the od after the unpack from the ebuild. I already know the tarball is wrong. That's why the sed is in src_unpack. (In reply to comment #10) > No, do the od after the unpack from the ebuild. I already know the tarball is > wrong. That's why the sed is in src_unpack. > Sorry about that. Here's the output: Chaos-X3 ~ # rm -R /var/tmp/portage/games-board/kwappen-1.1.5/ Chaos-X3 ~ # ebuild /usr/portage/games-board/kwappen/kwappen-1.1.5.ebuild unpack * kwappen-1.1.5.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking kwappen-1.1.5.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking kwappen-1.1.5.tar.gz to /var/tmp/portage/games-board/kwappen-1.1.5/work >>> Source unpacked. Chaos-X3 ~ # cd /var/tmp/portage/games-board/kwappen-1.1.5/work/kwappen-1.1.5/doc/pt Chaos-X3 pt # grep "title>Op" index.docbook | od -cN14 0000000 < t i t l e > O p 215 233 e s < 0000016 Chaos-X3 pt # In other words, same output as from the source tarball and from what I got after the emerge error. So after doing some reading on the sed docs, I tried this command, factoring in the octal notation, as a test: sed -i -e "122 s/Op\o215\o233/OpHI/" index.docbook and it worked!: </sect1> </chapter> <chapter id="options"> <title>OpHIes</title> <sect1 id="autoshrink"> <title>Tempo da autoredução</title> <para> I put the new code in the ebuild, and it now emerges OK. It's a simple one-line change: sed -i \ - -e "122 s/Op../Opï¿/" \ + -e "122 s/Op\o215\o233/Opï¿/" \ doc/pt/index.docbook \ An ebuild with this change will be attached; see if it works for you. Thanks for pointing me in the right direction with this! Created attachment 148026 [details]
Modified ebuild, with sed accounting for octal notation in the regexp script
What sed do you have that doesn't work with the current ebuild? (In reply to comment #13) > What sed do you have that doesn't work with the current ebuild? > The usual one, marked as stable: Chaos-X3 ~ # eix ^sed$ [I] sys-apps/sed Available versions: 4.1.5 4.1.5-r1 {nls static} Installed versions: 4.1.5-r1(11:27:01 AM 03/30/2008)(nls -static) Homepage: http://sed.sourceforge.net/ Description: Super-useful stream editor Now that I look at the changelog, the -r1 version was marked stable for x86 on March 28th, only five days ago from this writing (see Bug 215072)...would this change (from the changelog) " 30 Jan 2008; Mike Frysinger <vapier@gentoo.org> +files/sed-4.1.5-prototypes.patch, +sed-4.1.5-r1.ebuild: Default to using regex from the libc so as to get a smaller sed binary. " affect anything? Same sed I'm using and it works fine for me. Please figure out why the sed in the ebuild doesn't work for you. (In reply to comment #15) > Same sed I'm using and it works fine for me. Please figure out why the sed in > the ebuild doesn't work for you. > Hmm...what are your LANG and LC_ALL locale variables set to? I did some more testing, and I'm pretty sure I've found the problem: * when environment vars are set to 'LANG=C' and 'LC_ALL=C': sed commands in the original ebuild works * when environment vars are set to 'LANG=en_US.UTF8' and 'LC_ALL=en_US.UTF8' (as I have set by default on my machine): sed commands in the orginial ebuild do NOT work changed it to use epatch instead of sed. reopen if it still doesn't work. |
