| Summary: | xfce-base/libxfce4util-4.7.0 : no rule to make target "ru.gmo" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vladimir <v_2e> |
| Component: | Current packages | Assignee: | XFCE Team <xfce> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | axiator, const, joost.ruis, skobkin-ru |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
Russian translation file corrected ebuild to copy ru.po file from "./files/" catalog into the source code dir. Fixed in some way libxfce4util-4.7.0-r1.ebuild libxfce4util-4.7.1.ebuild |
||
|
Description
Vladimir
2009-12-21 15:16:24 UTC
Created attachment 213675 [details]
build.log
A xomplete build log for xfce-base/libxfce4util-4.7.0
Looks like an upstream bug to me: there's po/ru.po, but ru is not listed in po/LINGUAS. (In reply to comment #2) > Looks like an upstream bug to me: Ok. I have reported this bug upstream. Here is a link: http://bugzilla.xfce.org/show_bug.cgi?id=6100 (In reply to comment #2) > there's po/ru.po, but ru is not listed in po/LINGUAS. > By the way, there actually isn't po/ru.po in tarball right now. But i can clearly see this file in Xfce project's GIT repository: http://git.xfce.org/xfce/libxfce4util/tree/po And also they have just deleted "po/LINGUAS" and "po/ChangeLog" in reply to this bugreport. My temporary solution is to download ru.po file from Xfce's homepage and copy it into the po/ directory during install. The ru.po file and corrected ebuild for this purpose follow. Created attachment 213708 [details]
Russian translation file
Created attachment 213710 [details]
corrected ebuild to copy ru.po file from "./files/" catalog into the source code dir.
Same issue :) (In reply to comment #4) > And also they have just deleted "po/LINGUAS" and "po/ChangeLog" in reply to > this bugreport. > Can someone try? (In reply to comment #9) > > Can someone try? > As I have already mentioned, I have not only tried, but I have already emerged libxfce4util-4.7.0 on my system using my local overlay. But it seems to me, that if this bug is fixed by upstream developers and the correct libxfce4util tarball is there on Xfce's homepage, it must be just a question of time for Gentoo mirrors to synchronize with it. Still I'm not sure about that. You can always use your own home-grown overlay to make changes proposed by me and to use Xfce just like I do. :) Same thing with the greek el variable. Thought, I should report that here. When removing el from linguas, libxfce4util-4.7 compiles fine. Details can be seen here: http://forums.gentoo.org/viewtopic-t-808632.html (In reply to comment #10) > (In reply to comment #9) > > > > Can someone try? > > > > As I have already mentioned, I have not only tried, but I have already > emerged libxfce4util-4.7.0 on my system using my local overlay. But it seems to > me, that if this bug is fixed by upstream developers and the correct > libxfce4util tarball is there on Xfce's homepage, it must be just a question of > time for Gentoo mirrors to synchronize with it. That would be someone on the xfce team (ie. myself). I'm trying to help, but not getting much feedback besides "it's broke" > Still I'm not sure about that. > You can always use your own home-grown overlay to make changes proposed by me > and to use Xfce just like I do. :) I see proposed fixes by you that include grabbing some file from somewhere and putting it in files/ - this is not the upstream fix, afaik. --- I'm asking if someone could please test the upstream fix (remove po/LINGUAS and po/ChangeLog). I can't reproduce this issue easily, so I need to rely on someone that has a broken system that can verify the upstream fix. (In reply to comment #13) > I'm asking if someone could please test the upstream fix (remove po/LINGUAS and > po/ChangeLog). I can't reproduce this issue easily, so I need to rely on > someone that has a broken system that can verify the upstream fix. > I'm sorry. It seems, I just didn't understand you right last time. :) The thing is that I have tried to remove "po/LINUGUAS" using my own patch for this. That patch worked ok, but it didn't help. And this is perfectly understandable, because there is NO "ru.po" file in the tarball at all. But it IS there in the latest archive on Xfce's webpage ( http://git.xfce.org/xfce/libxfce4util/snapshot/libxfce4util-4.7.0.tar.bz2 ). That is why removing "po/LINUGUAS" just cannot help to compile nonexistent file. (In reply to comment #11) > Same thing with the greek el variable. Thought, I should report that here. > > When removing el from linguas, libxfce4util-4.7 compiles fine. > Exactly! This is just the very same problem. There is NO "el.po" file in the tarball located on Gentoo mirrors, but there IS such file on Xfce's webpage (see the link above). Making all in po make[2]: *** No rule to make target `el.gmo', needed by `all-yes'. Stop. Same problems for me. What we now know: 1) Removing po/LINGUAS & po/ChangeLog (upstream fix) doesn't work 2) Using modified distfile has potential to work, but fails because ./configure can't be found and eautoreconf fails. So, that leaves using the ru.po file in FILESDIR, but I'm not comfortable putting all the broken translations in that way. From this bug, at least two are "broken" in this fashion. If anyone has a working fix that does not involve FILESDIR, I'll be happy to evaluate and commit. Otherwise, I guess we will have to mask it soon (but I'd rather not) Thanks. (In reply to comment #16) > What we now know: > 1) Removing po/LINGUAS & po/ChangeLog (upstream fix) doesn't work > 2) Using modified distfile has potential to work, but fails because ./configure > can't be found and eautoreconf fails. There is 'autoge.sh' file in the original tarball (the one from Xfce's website). Simple running "./autogen.sh" "make" seems to work fine. I don't know if it helps to make an appropriate .ebuild, but I hope so. The "tarball" you are referring to (the one from git.xfce.org) is a snapshot of the repo at the time 4.7.0 was tagged. That's not the same tarball that's available on the mirrors (archive.xfce.org). We are using the one from archive.xfce.org because that's the one we're supposed to use. The most obvious fixes for this are imho: a) wait for 4.7.1 or b) take a snapshot from current git master. I'm currently considering the latter but wonder if it's worth it considering that this is a devel release and 4.7.1 will probably come soon. Created attachment 214555 [details] Fixed in some way libxfce4util-4.7.0-r1.ebuild (In reply to comment #18) > The "tarball" you are referring to (the one from git.xfce.org) is a snapshot of > the repo at the time 4.7.0 was tagged. That's not the same tarball that's > available on the mirrors (archive.xfce.org). We are using the one from > archive.xfce.org because that's the one we're supposed to use. > The most obvious fixes for this are imho: a) wait for 4.7.1 or b) take a > snapshot from current git master. I actually knew nothing about archive.xfce.org existence. :) Sorry about that. > I'm currently considering the latter but wonder if it's worth it considering > that this is a devel release and 4.7.1 will probably come soon. I am not sure if it is worth doing anything with, but I have already made some kind of "fixed" ebuild. It's disadvantages are: - I had to add '--enable-maintainer-mode' because it cannot be compiled without; - It runs the './configure' script for 2 times. It's advantage: - It lets one install libxfce4util-4.7.0 using a "master" tarball from Xfce's GIT repository. Created attachment 214559 [details]
libxfce4util-4.7.1.ebuild
Good news!!!
I reopened again this bug on bugzilla.xfce.org describing our problems and the developers answered almost immediately by releasing a new version (4.7.1).
A simple renaming an old .ebuild works fine on my system, so I decided to attach this file here.
Still I think we must do something with all those languages. I guess we should use the LINGUAS variable from make.conf in some way. Am I right? What suggestions? (In reply to comment #21) > Still I think we must do something with all those languages. I guess we > should use the LINGUAS variable from make.conf in some way. Am I right? > What suggestions? > It's already using LINGUAS from make.conf. LINGUAS="ru" and only, --- /usr/share/ --- /usr/share/locale/ --- /usr/share/locale/ru/ --- /usr/share/locale/ru/LC_MESSAGES/ >>> /usr/share/locale/ru/LC_MESSAGES/libxfce4util.mo --- /usr/share/doc/ this gets installed. if you don't set linguas at all, everything gets installed, that's the way it's supposed to work i personally use LINGUAS="en" in make.conf to avoid extra langs... 4.7.1 in portage *** Bug 298908 has been marked as a duplicate of this bug. *** |
