After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 656465 - There are some missing files from POTFILES.in
There are some missing files from POTFILES.in
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: User interface
Git
Other Linux
: Normal normal
: Git
Assigned To: Pitivi maintainers
Pitivi maintainers
Depends on:
Blocks:
 
 
Reported: 2011-08-13 16:02 UTC by Daniel Mustieles
Modified: 2011-08-15 15:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fixes error in POTFILES.in (309 bytes, patch)
2011-08-13 16:08 UTC, Daniel Mustieles
none Details | Review
translation: Add missing files to POTFILES.in (1013 bytes, patch)
2011-08-13 16:51 UTC, Thibault Saunier
committed Details | Review

Description Daniel Mustieles 2011-08-13 16:02:44 UTC
It seems there are some missing files in POTFILES.in, so D-L can't generate an updated POT file.

Here is the error that D-L shows:

There are some missing files from POTFILES.in:

    * data/ui/alignmentprogress.ui
    * data/ui/cliptransformation.ui
    * data/ui/depsmanager.ui
    * pitivi/formatters/etree.py

Many thanks for your help
Comment 1 Daniel Mustieles 2011-08-13 16:08:29 UTC
Created attachment 193775 [details] [review]
Fixes error in POTFILES.in

T
Comment 2 Thibault Saunier 2011-08-13 16:51:18 UTC
Created attachment 193778 [details] [review]
translation: Add missing files to POTFILES.in

Author is Daniel Mustieles
Comment 3 Thibault Saunier 2011-08-13 16:52:40 UTC
Comment on attachment 193778 [details] [review]
translation: Add missing files to POTFILES.in

Attachment 193778 [details] pushed as d087741 - translation: Add missing files to POTFILES.in
Comment 4 Claude Paroz 2011-08-13 19:40:46 UTC
The patch still needs work. .ui files need to be prefixed by [type: gettext/glade] to be properly parsed by intltool.

Isn't it possible to commit fixes directly in the GNOME Git repo of pitivi?
Comment 5 Piotr Drąg 2011-08-13 23:44:23 UTC
I fixed this in that commit: http://git.gnome.org/browse/pitivi/commit/?id=4486a59cebd4a997a2968313694b61144a5915d4

I hope you don't mind. I did it several times with other modules in the past few months.
Comment 6 Daniel Mustieles 2011-08-14 10:49:37 UTC
Ok, I didn't know .ui file must be prefixed. i'll take it in account next time :).

This bug is now fixed, so I'm closing it.

Many thanks for your quick responses :)
Comment 7 Thibault Saunier 2011-08-15 13:53:35 UTC
Piotr, I would rather you don't push directly because we actually use git.pitivi.org as official repo. I had actually pushed the patch to the official repo, and got to do dirty merges to be able to get the 2 repos synced together again.

Anyway thanks for your help and your responsivness :)
Comment 8 Claude Paroz 2011-08-15 14:05:47 UTC
This out-of-GNOME git policy is clearly suboptimal and misleading, as it prevents GNOME hackers to directly contribute to Pitivi code. Of course, it's your choice, but you shouldn't be too much surprised to get commit in the GNOME repo.
Comment 9 Thibault Saunier 2011-08-15 14:21:19 UTC
Getting patches pushed in our repo without the approbation of one of the person that have write access to our Git repo is definitely something we don't want to happen. I quite agree that having 2 "official" repos is not really a good idea, more because we loose time syncing them but not really because people coming from gnome would be able to push patches without us reviewing.
Comment 10 Piotr Drąg 2011-08-15 14:57:54 UTC
I'm sorry, I didn't know pitivi doesn't follow usual git.gnome.org rules. I won't push to pitivi directly again.
Comment 11 Jean-François Fortin Tam 2011-08-15 15:12:42 UTC
For the record/to clarify: even among pitivi developers, we tend to have this semi-formal rule of requesting that at least one other dev has reviewed changes before they get pushed to the repo, even if the author has commit access. Peer review :)