Bug#748984: recode html..utf8 breaks existing UTF-8
When converting text from HTML to UTF-8, existing and valid UTF-8 characters get mangled. I'm far from my things and with rather limited connectivity. The truth is that I now live in an hospital, and likely for good, matter of speaking :-) . So, Recode and my other projects are opened to takers! Still have to think how to best trigger such transitions... For the problem you describe, could it be that you need the -d option, or such? I'm telling this from memory, and may be wrong. François
Bug#610748: From the shell there is no way to adjust what problems cause an error
Le 2011-01-21 19:14, jida...@jidanni.org a écrit : From the shell there is no way to adjust what problems cause an error exit value. At least from reading (info (recode) Task level). Please add examples if there is a way. Well, Recode has three settings for when to set the exit status. The most lenient is activated with -f, in which case only system errors or library mis-usage causes the exit status to be set. By default, without -f nor -s, Recode sets the exit status as above, and also in case of invalid or untranslatable input. It also tries (but not always succeed) to detect if output is going to be ambiguous at some later recode-back time. The most harsh is activated with -s, Recode then sets the exit code as above, or if input is not canonically coded (and it also prevents itself from completing recoding tables for making the recoding reversible). I think these options are documented in the manual. I also just added the above notes in the Synopsis node. If you have some more specific need, please describe the problem you actually have. Thanks! François -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608012: remove 'free' from man page
On 2010-12-25 18:55, jida...@jidanni.org wrote: Package: recode Version: 3.6-17 Severity: wishlist I say remove the word 'free' from all the places in the man page, as e.g., man cat(1) doesn't say free cat. Well, to be blunt, Recode is not bound to look like cat. And besides, you name your own dog as you see fit, don't you? :-) You don't say 'free' at the top on Info. Yes, you're right, I could use your report and add 'Free' there as well, as a way to tease you a bit :-). But I'm not going to be such a bad guy. In the README file for version 3.7-beta2, there is already: + The name has been changed from Free recode to Recode -- as Free was a four letter word to some people :-). The man page is automatically generated by help2man, a separate package. help2man recognizes Free and GNU prefixes, so it probably picks Free from somewhere else. OK, I'll look around and remove some more Frees. Or add a paragraph saying why you say 'free'. Recode is free software. I used Free instead of GNU, because the FSF is entitled to the GNU prefix and may (rightly) control how is it used. When Recode was called GNU recode, the FSF was requiring a level of obedience that went overboard, and I decided to break free, so to speak. Beyond free programs, there should also be free programmers :-). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#462004: FTBFS with GCC 4.3: width of 'ignore' exceeds its type
[Martin Michlmayr] Your package fails to build with GCC 4.3. Version 4.3 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. You can reproduce this problem with gcc-4.3 or gcc-snapshot from unstable. Automatic build of recode_3.6-14 on em64t by sbuild/amd64 0.53 ... gcc -DLIBDIR=\/usr/lib\ -DHAVE_CONFIG_H -I.. -I. -I../lib -I../libiconv -g -Wall -D_REENTRANT -O2 -c charname.c -fPIC -DPIC -o .libs/charname.lo In file included from common.h:140, from charname.c:20: recodext.h:221: error: width of 'ignore' exceeds its type make[3]: *** [charname.lo] Error 1 Remove the bit-field and it will work. Hi, Martin, Debian people, and Recode pre-testers. This should be corrected for the next release of Recode. Thanks! Instead of removing the bit-field, I reduced it from 2 to 1, as there are other bool fields having 1 as a bit field in the same file, and this does not apparently generate recent problems from other testers. But I'm pretty sure that if I once used 2 instead of 1, it came from the fact, when bool is not available and rather made an enum of 0 and 1, that some compiler (I do not remember which) saw 0 and 1 as signed integers (while I was thinking of those two constants as unsigned), and complained that 1 as a bit field was too small, not having enough room for the sign bit any integer should have. I do remember I was not happy being forced to use 2 bits for holding a boolean. While it is true that the bit field could be made smaller, and more tight for the value it receives, I'm rather surprised to see that this will be an error in some incoming GNU C compiler. A warning, I would easily understand. But an error? Does it mean that the programmer is about to loose, with this incoming compiler, the freedom of deciding the precise bit allocation of his fields? It looks pretty wrong to me. What is the rationale? -- François Pinard http://pinard.progiciels-bpi.ca
Bug#420278: recode: Typos in info manual
[Reuben Thomas] [minor spelling or English corrections to the Recode manual] All done! Thanks, Reuben! :-) -- François Pinard http://pinard.progiciels-bpi.ca
Bug#376124: subversion: svn doesn't report modified file when timestamp has not changed
[Peter Samuelson] I reassigned it because [the bug] believe it's _wrong_ to change a file's contents and hide this fact by restoring the original timestamp. No doubt, here, that you did what your believe is right. It's the correct thing to do. Automated processes [...] don't care about informational contents, they care about actual bits and bytes. While it's true that the 'modification time' of a file is sometimes used merely as information for humans, there are also quite a few instances where it is used by automated processes. Thanks for your comments. Indeed, Recode has been mainly written for humans :-). If one uses Recode in context of automated processes, one should adapt his/her scripts to use option `-t' whenever appropriate. Why would users either assume or desire that after running recode on their files, that the files will have their old timestamps? This is explained within the very message to which you replied. Keep happy, and have a good day! -- François Pinard http://pinard.progiciels-bpi.ca
Bug#333452: recode(GNU/k*BSD): FTBFS: out of date config.sub/config.guess
[Aurelien Jarno] [...] it can also be done automatically using the method described in /usr/share/doc/autotools-dev/README.Debian.gz Hi, Aurelien. If you think the contents of this file may be useful outside Debian, would you be kind enough to send me a copy that I could peruse? Thanks! -- François Pinard http://pinard.progiciels-bpi.ca Recode site http://recode.progiciels-bpi.ca Recodec site http://recodec.progiciels-bpi.ca
