| Summary: | emelfm2-0.0.5.ebuild | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | ares <ares> |
| Component: | New packages | Assignee: | Desktop Misc. Team <desktop-misc> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | enhancement | CC: | ares, brad, dsd, hollywoodb, mikpolniak |
| Priority: | High | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emelfm2-0.0.5.ebuild (New)
emelfm2-0.0.8.ebuild melfm2-0.0.8.ebuild locale-workaround.patch emelfm2-0.0.8.ebuild |
||
|
Description
ares
2004-02-27 11:38:00 UTC
Created attachment 26481 [details]
emelfm2-0.0.5.ebuild (New)
Created attachment 30413 [details]
emelfm2-0.0.8.ebuild
New version emelfm2, support version gtk+2.4
would love to see this worked with & added to portage... getting this error when attempting to execute emelfm2: The error above usually means that you've set the environment variable G_BROKEN_FILENAMES to something. Then GTK+2 is suppossed to work with file names in your locale. Though, it is impossible to do this without a known locale. To prevent crashes please either unset G_BROKEN_FILENAMES or adjust your locale. (note there is no 'error above', just this) Created attachment 33362 [details]
melfm2-0.0.8.ebuild
Here's my take on this ebuild.
comment #4's ebuild works fine for me... still getting error about G_BROKEN_FILENAMES... more info on that here: http://bugs.gentoo.org/show_bug.cgi?id=23254 output of "locale": LANG= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= from the emelfm2 author: ...this means your locale is set to C but you have exported G_BROKEN_FILENAMES. gtk has to know from what locale it should convert character to utf8. thus, as the message states, either set a different locale or unset G_BROKEN_FILENAMES. the 'no error above' note in comment #3 will be fixed, not yet known if by updating 0.0.8 sources or next release... 'export LANG=en_US.UTF-8' allows for running emelfm2 in my case, however I'd like to get this fixed on a better level commenting out lines 172-185 of src/e2_main.c removes the "death" reaction to my setup and allows emelfm2 to run without panicking... however I'm not sure what side-effects this may have, other than causing emelfm2 to fall back on utf8... imo, users using another setting will have it set anyways... on commenting these lines from the author: if you do this, e2 is likely to crash sooner or later because there is no error checking in case the utf8 conversion fails. gtk+2 uses only utf8 internally. why do you export G_BROKEN_FILENAMES at all if your file names aren't broken? if your users export G_BROKEN_FILENAMES without having set up a locale, they will break all gtk+2 programs. if there was a way to detect the stuff that G_BROKEN_FILENAMES is for, it would have been done by gtk and G_BROKEN_FILENAMES wouldn't exist. but there is no way, and thus gtk+2 has to let the user adjust it and if he adjusts it wrong, it will break. (i mean if you export G_BROKEN_FILENAMES you should be aware of what you're doing) the only bad thing about e2 is, that it denies work in general instead of handling each conversion error. other programs that don't rely on file operations that heavily might handle it differently. for e2, this was the easiest way to go right now, since it is a port of the gtk1 version. even so, I've never had any gtk2 apps 'break' because of this, and emelfm2 seems to be perfectly happy with this... perhaps a locale check that decides whether or not to patch e2_main.c followed by an einfo descript, or a better way? I realized I can recieve the same result as previous post by simply commenting line 183 (the exit command)... doing this also lets emelfm2 show its mystical G_BROKEN_FILENAMES error and run properly (imo)... This is probably a better solution than commenting out that entire block because it makes the user aware of the problem, not that I feel it will make a big difference... I'm still open to ideas ;) /me slowly learns to read this strange code Have you tried creating a file from the command line with non-ASCII characters (e.g. Have you tried creating a file from the command line with non-ASCII characters (e.g. äää) in it and then seeing how this package can cope after your little hack? a file containing " a file containing "£££££" its fine with, no problem that I see... it determines the filetype exactly the same 'file' does... attempting to save a file with the above string in the name results in this: Could not build file name from 'file:///home/hollywoodb' and '£££££': Invalid byte sequence in conversion input attempting to rename a file alone on the command line with the same string results in '?????' in place of '£££££" so I'm doubting this is an emelfm2 problem. *** Bug 38020 has been marked as a duplicate of this bug. *** The words of the author seem to contradict how the code behaves. If G_BROKEN_FILENAMES is _not_ set, then it is assumed that all filenames are read as UTF-8. However, the code is using logic such that: 1. Read filenames 2. Convert from locale to utf8 This is done in all situations, no matter if G_BROKEN_FILENAMES is set or not. The way I have previously handled this is to just fall back to ISO-8859-1 ---> UTF-8 conversion if we can't detect the locale. This isn't technically correct, but it works for those people who do not have a locale set. It may be better if this was a configurable option. Maybe we (as an OS) should be advising users to set a locale in the same way that we set a timezone. Also, simply commenting out the exit call or check does not avoid the problem, as the app is unable to deal with any files with foreign characters in them. I'll see if I can patch up the basic conversion functions as described above. Created attachment 33824 [details, diff]
locale-workaround.patch
Created attachment 35843 [details]
emelfm2-0.0.8.ebuild
fixed to include dsd's locale-workaround.patch
fixed KEYWORDS from x86 to ~x86
I've been using this quite extensively, and its pretty stable
Maybe we should investigate sending that patch upstream for review, this is a bit of a problem for the application itself, IMO. Just tried the Just tried the £££££ thing myself. Named the file as such on a bash prompt and found that it doesn't display properly in bash, but emelfm2 picked it up. I have no variables set and launched it with the new -i flag. The -i flag is used on the advice of the application's author in cases where LANG is not set, and appears to work well. I'm going to commit this so more eyes get a look at it, if anyone reading this wants to take maintainership let me know, otherwise I'll take care of it. New version avaible emelfm2-0.0.9 That's the version I added. d8) |
