GNOME Bugzilla – Bug 730122
cerbero: Add support to latest pitivi + add a linux bundling system based on AppImageKit
Last modified: 2014-06-17 13:46:15 UTC
I have a branch where I implement all that, it has been running daily to generate pitivi bundles on: https://jenkins.arracacha.collabora.co.uk/view/pitivi/job/pitivi-bundling/ The branch where this is implement is avalaible at: https://gitlab.com/thiblahute/cerbero/commits/gi+pitivi That branch is based on andoni gi branch and include many other changes: * Add various recipes: - Update to Gtk3+ - gnome-icon-theme - hicolor-icon-thene - numpy - python3 - AppImageKit - gst-validate (part of gst-devtools but only focuses on validate) * Some package version updates * Add a Linux bundle packager How do you want to proceed to move forward with that merging? (btw I could not find any cerbero component nor product, it would be nice to have).
Last time I reviewed there was still some issues to review: * Check that all the new recipes are listing files correctly * In the Appkit packager, use the packages files listing to only include the files needed by the application package instead copying the whole prefix and than removing files that are not needed. This is what the Appkit packager is currently doing: + def _copy_installdir(self): + shell.call("rm -rf %s" %(self.tmp_install_dir), fail=False) + shell.call("cp -pR %s %s" %(self.config.install_dir, self.tmp_install_dir)) + + def _clean_install_path(self): But it should be using self.package.files_list() like in https://gitlab.com/thiblahute/cerbero/blob/master/cerbero/packages/osx/packager.py#L375
This is great news ! I'd like to first push the gi stuff alone (from bug #711030) first though, including updating the new recipes that andoni's branch adds (gobject-introspection for example) since there are fixes upstream.
g-i support has been pushed upstream It would be nice if you could split the various cerbero improvements (like the new app bundler) from the commits adding support for pitivi.
(In reply to comment #1) > Last time I reviewed there was still some issues to review: > * Check that all the new recipes are listing files correctly I did that on my lastest branch. I also added a command "find-provided-files" helping people figure out what files are installed with a particular recipes: https://gitlab.com/thiblahute/cerbero/blob/gi+pitivi/cerbero/commands/findprovidedfiles.py > * In the Appkit packager, use the packages files listing to only include the > files needed by the application package instead copying the whole prefix and > than removing files that are not needed. This is now done on my latest bundler+pitivi branch: https://gitlab.com/thiblahute/cerbero/commits/bundler+pitivi (In reply to comment #3) > g-i support has been pushed upstream > > It would be nice if you could split the various cerbero improvements (like the > new app bundler) from the commits adding support for pitivi. I organized the commit stack as followed: - Add core features to cerbero, including the bundler - Clean and add needed recipes and packages to add support to pitivi
There is already a similiar option in the build command to test the installed files with --missing-files. We should probably create a new command named validate-recipe that rebuilds a recipe from scratch and shows the information about the installed files and more checks can be added in the future.
(In reply to comment #5) > There is already a similiar option in the build command to test the installed > files with --missing-files. > We should probably create a new command named validate-recipe that rebuilds a > recipe from scratch and shows the information about the installed files and > more checks can be added in the future. What is the difference between that and my find-provided-files command? Looks quite similar to me in the end.
It's the same, that's why I am proposing to move it to a different command and make it more generic to test recipes, a validation tool for new recipes.
(In reply to comment #7) > It's the same, that's why I am proposing to move it to a different command and > make it more generic to test recipes, a validation tool for new recipes. Right, sure :)
(In reply to comment #7) > It's the same, that's why I am proposing to move it to a different command and > make it more generic to test recipes, a validation tool for new recipes. OK, I changed the name and cleaned it a bit. I also made sure Gtk variant disabled by default it now needs to be explicitely activated by the user (so we avoid to bring it in because of librsvg or clutter) if not actually wanted by the user. I removed the pygobject dependency on gobject-introspection as the dependency is automatically added with the gi variant
1) As discussed in IRC the lirsvg package should splitted in 2: * librsvg: library used by gst-plugins-bad * librsvg-gtk: gtk module (enabled only with the gtk+ variant) It's ugly, but this way we can have the gtk+ variant enabled by default but avoid pulling the gtk dependency when building gst-plugins-bad. 2) In gst-plugins-bad, librsvg is added as a dependency, thus building the plugin depending on it, but this plugin is not listed in the recipe 3) The gtk+-3.0 package duplicates other packages that are in the base-system package like pango, cairo, gdk-pixbuf, etc... The correct way is to add base-system as dependency to gtk+-3.0 package 4) Python 3 prefix is hardcoded to Python 3.3 5) We need a variant for gtk+2 and gtk+3 (unfortunately gtk+2 is still required in some C# mono projects) but there is not need to add it now, just rename gtk+ variant to gtk+3 6) If there is a python3 variant, the python variant should be probably renamed to python2 to be more explicit 7) In the python recipe you could probably use * for encodings/*.py and for other directories.
(In reply to comment #10) > 1) As discussed in IRC the lirsvg package should splitted in 2: > > * librsvg: library used by gst-plugins-bad > * librsvg-gtk: gtk module (enabled only with the gtk+ variant) > > It's ugly, but this way we can have the gtk+ variant enabled by default but > avoid pulling the gtk dependency when building gst-plugins-bad. Done > 2) In gst-plugins-bad, librsvg is added as a dependency, thus building the > plugin depending on it, but this plugin is not listed in the recipe Fixed > 3) The gtk+-3.0 package duplicates other packages that are in the base-system > package like pango, cairo, gdk-pixbuf, etc... The correct way is to add > base-system as dependency to gtk+-3.0 package Done > 4) Python 3 prefix is hardcoded to Python 3.3 Do you have any idea how that could be properly implemented? > 5) We need a variant for gtk+2 and gtk+3 (unfortunately gtk+2 is still required > in some C# mono projects) but there is not need to add it now, just rename gtk+ > variant to gtk+3 I renamed gtk to gtk3 so we could re add gtk2 in the future. > 6) If there is a python3 variant, the python variant should be probably > renamed to python2 to be more explicit There is no python2 variant, but it could be added in the future. > 7) In the python recipe you could probably use * for encodings/*.py and for > other directories. It is not supported in the search algorithm for python files. I thought it was on purpose so recipes cleanly defines the exact files that should be picked.
> > 6) If there is a python3 variant, the python variant should be probably > > renamed to python2 to be more explicit > > There is no python2 variant, but it could be added in the future. Actually there is a python variant but it is not used at all from what I can see. What is it supposed to be used for?
This branch has been merged today, closing the bug.