GNOME Bugzilla – Bug 710833
strange locale-uninstalled rules
Last modified: 2013-10-30 21:56:32 UTC
Trying to add pitivi to Continuous, I get: make[2]: Entering directory `/ostbuild/source/pitivi/_build/po' /bin/sh /ostbuild/source/pitivi/install-sh -d /ostbuild/results.././locale mkdir: cannot create directory '/ostbuild/results..': Read-only file system mkdir: cannot create directory '/ostbuild/results..': Read-only file system make[2]: *** [install-data-yes] Error 1 make[2]: Leaving directory `/ostbuild/source/pitivi/_build/po' make[1]: *** [locale-uninstalled] Error 2 make[1]: Leaving directory `/ostbuild/source/pitivi/_build' make: *** [install-recursive] Error 1 ob: pid 4347 exited with code 2 Build of pitivi failed This looks like it comes from the locale-uninstalled rule in the toplevel Makefile.am; I can't fathom what it's trying to do, and git blame just points back at the first time i18n was introduced.
Created attachment 258051 [details] [review] build: Delete locale-uninstalled rule This breaks the build in Continuous, and I don't know why it'd be necessary. Hopefully pitivi's authors use jhbuild or the like and thus install the translations.
Created attachment 258057 [details] [review] manifest: Add pitivi More apps!
Attaching the manifest patch here just for my own reference, so once this bug is fixed it can get on the Continuous train.
Disclaimer : I am not an autotools expert. That patch still looks suspicious to me, is there a good reason for deleting that rule except "it makes stuff work for me" ? We don't use jhbuild, and use pitivi completely uninstalled without any problem, and we would like to keep it that way. Also, it's kind of hard for us to reproduce the issue, as "Trying to add pitivi to Continuous" is not really a way to reproduce, can you tell us what continuous is trying to do that fails, that way we'll be able to fix that bug ?
(In reply to comment #4) > That patch still looks suspicious to me, is there a good reason for deleting > that rule except "it makes stuff work for me" ? See below. > We don't use jhbuild, and use pitivi completely uninstalled without any > problem, and we would like to keep it that way. Ok. I understand that, and I don't want to break it. (Personally though I gave up on it for my apps, and I just use "jhbuild make" to install in the jhbuild root) > Also, it's kind of hard for us to reproduce the issue, as "Trying to add pitivi > to Continuous" is not really a way to reproduce, can you tell us what > continuous is trying to do that fails, that way we'll be able to fix that bug ? The executive summary is gnome-continuous is a package-like build system, except automated continuously. What's very important is that it builds every module in *exactly* the same way: env NOCONFIGURE=1 ./autogen.sh ./configure --prefix=/usr --sysconfdir=/etc make make install DESTDIR=/tmp/tmpdestdir Now since pitivi is packaged, presumably this should fail in the same way inside dpkg/rpm...except now that I look, it doesn't. From the latest koji log in Fedora: http://kojipkgs.fedoraproject.org//packages/pitivi/0.15.2/5.fc21/data/logs/noarch/build.log if test -d po; then \ make -C po datadir=../. install; \ fi appears to work. Except if you look carefully, it's creating files outside of the buildroot: installing ar.gmo as /builddir/build/BUILDROOT/pitivi-0.15.2-5.fc21.noarch.././locale/ar/LC_MESSAGES/pitivi.mo Which Continuous is more strict about. Apparently it works in Debian too, I don't see any patches for this in the sid package. (They do carry a patch to disable pitivi's "devel mode")
Created attachment 258601 [details] [review] build: Don't attempt locale-uninstalled bits if DESTDIR is set How about this patch? It's a lot simpler and should hopefully avoid breaking you running uninstalled.
This looks way less intrusive to me already, I don't see no reason why we shouldn't merge this now. As stated before, I'm far from autotools mastery, and none of the two other current maintainers are either, so there might be an issue here that I could fail to see, thanks for the patches anyway and sorry for the low reactivity :)
Thanks! I'll take that as an accepted-commit-now even though you didn't change the patch status in Splinter. (Do you guys use Splinter/Bugzilla for patches?) Please ping me on IRC (walters) or reopen if you have any issues! Attachment 258601 [details] pushed as 5c94a24 - build: Don't attempt locale-uninstalled bits if DESTDIR is set
(In reply to comment #8) > Thanks! I'll take that as an accepted-commit-now even though you > didn't change the patch status in Splinter. (Do you guys use > Splinter/Bugzilla for patches?) OK, I am OK with that, not sure it was the perfect patch, but it should not break our stuff, hopefully :) about splitter/Bugzilla, it mainly depends on how big branches are, handling a big patch set in here is not exactly great so in that case we handle it differently, but in the case of a single patch, it is usually how we receive contributions yes. Thanks for your patch.
That was not an accepted-commit-now for the record, but as thibault doesn't seem to be against that patch either then no harm done.
So while pitivi builds in Continuous now, it doesn't actually run due to the dependencies on PyXDG and NumPy. The first is really duplicative of what we already have in GLib, so I'll work on a patch to drop it unless someone objects. Looks like NumPy is already a "soft" dependency. Will open further bugs for any future work.
(In reply to comment #11) > So while pitivi builds in Continuous now, it doesn't actually run due to the > dependencies on PyXDG and NumPy. The first is really duplicative of what we > already have in GLib, so I'll work on a patch to drop it unless someone > objects. I would be happy to drop that dep :) > Looks like NumPy is already a "soft" dependency. It is a runtime dep, and right now we do not actually need it as it is for a feature that has not been reimplement yet after the port to GES.