The kde-i18n packages need to be updated to 3.1.2
Ugh, just looked at the i18n packages. Haven't messed with them before as english is my native language. Anyway, it seems like we could simplify this a whole lot more and eliminate the need for this many different ebuilds and directories. Possible an env var: KDE_I18N_LANG="de" or something like this. I'll have to think about this a little more, but I put these comments here to at least get them recorded.
Unfortunatley, I tried to package the big one for our office (kde-i18n). It built but when it was making the package (tbz2) it failed with: !!! CATEGORY info missing from info chunk, aborting... Would you like a seperate bug report.
KDE 3.1.3 is now in portage, but kde-i18n ist still for 3.1.1. That should be fixed ASAP.
*** Bug 26664 has been marked as a duplicate of this bug. ***
we're working on a fix for this, better than what's already in portage now.
Any progress on that? For example, kde-i18n-3.1.4 won't compile after just renaming the old ebuild, since the name of the untared packages seems to have changed (from kde-i18-de to kde-i18n-de-3.1.4).
Yeah, I'm about 1 step away from committing an ebuild that encompassess all of the possible language configurations. It's been an arduous process at best. :) Anyway, just to let you know that it is still being actively worked on.
Please check out the new ebuild at kde-base/kde-i18n First, set your LINGUAS environment variable to whatever languages you'd like: export LINGUAS="de se" then emerge the ebuild. It should be able to handle everything for you magically! Please report errors here.
For me it doesn't work. Wheneaver I specifies a Lingua, it try to download the whole kde-i18n packge >130MB or somethin. With the Line 34 changed to this: SRC_URI="$BASEDIR/kde-i18n/kde-i18n-$pkg-${PV}.tar.bz2" It works very well. Thanks!
Created attachment 18091 [details] a small patch Hi Caleb, don't know, if you read my edited comment in the forums about ebuild.sh grumbling, it couldn't cd ${S}, because ${WORKDIR}/kde-i18n-${PV} doesn't exist. Here's the fix. Also added RESTRICT="nomirror".
Created attachment 18093 [details, diff] huh, that was too much, fixed patch
I think this is because after you start the "emerge", if you cancel it before it finishes, then attempt to set LINGUAS, then try to run "emerge" again, it will continue doing what it was doing before. The only way to trick portage into making it work is to "touch" the ebuild so it will start over in calculating which files to download. I don't know anyway around this.
kde-i18n still doesn't work here, the only way to get it fetching & compiling only the language i want is to change line 23 into USE="${LINGUAS}" (hint from the german gentoo forum)
Did you see my comment above?
Yes, I read your comment above. When I export LINGUAS="de" and then start emerging kde-i18n it says that it would be building the german package but attempt to fetch the whole kde-i18n. If I 'touch' the ebuild between exporting LINGUAS and the emerge it works fine. But thats a solution for some geeks who are spending much time in bugs.gentoo.org or the forums. I think that there must be an easier solution.
The best solution I've got is that we have to modify portage somehow to be a little smarter in this instance. I'll keep looking into this...
Hi Caleb, isn't the kde-i18n.eclass obsolete now?
yep, it will be going away before long.
Going to resolve this as fixed. The i18n ebuild will be changing (for the better) once the use flag expansion in portage is fixed ( in 2.0.49-r8 or -r9 I believe). In the meantime, it works.
