Magnus Boman wrote:

On Tue, 2009-02-17 at 16:40 +0100, Stanislav Brabec wrote:

...

A: Such large change cannot be done in late beta or rc phase. It must be ready as soon as possible, only translation data file updates will have to be done in the rc phase.

rpmlint could be extended to catch all of the potential issues with packages that we build for openSUSE

rpmlint cannot do it. You need to perform actions on a complete source tree to perform this check, checking of build RPMs is not sufficient. Error can be caused by strings in the upstream SVN, outside of our spec files and outside OBS. There can be no check preventing it. If the package does not support translation in a standard automake->gettext way, forcing the check may fail in an arbitrary way (and guessing whether po files are supported exactly in the standard way is not trivial). Adding "make distcheck" to the %check stage of our packages would surely prevent many QA issues (including some translate-ability problems), but at cost of double compilation time.

...

Q: Isn't it best to modify OBS to support this?

A: No: - The tool has to have access to network.

When doing this during compile time, the tool doesn't have access to the network. Why would it be different if OBS had to handle it?

In my opinion, any action, that significantly modifies unpacked sources should be part of spec file (or macro) and not the Build Service, not counting the fact, that OBS simply cannot initiate any action in the middle of %prep script. Move it to OBS would make things even more opaque: - OBS would build different RPMs than rpmbuild. => You will not be able to fix rejects in po file patches. - Configuration file for translation update would be hidden somewhere deeply in the OBS repository configuration. => After linking to other repository, you would get a different RPM or failure. - Complete po files merge for the first 100 packages requires about 2 hours with a fast network, fast machine and low servers load. How you will schedule this action inside OBS itself? - It may merge buggy upstream translation. => You would have to design OBS API to control the merge behavior.

...

- String collecting may require manual intervence in case of upstream errors.

See rpmlint suggestion above

rpmlint cannot catch errors in the upstream SVN repository.

...

Q: Wouldn't it be better to modify %setup?

A: No: - It would bring additional "magical" divergence from upstream.

But if %setup is extended only in OBS and only for repositories that are actually built for SLE, it wouldn't diverge at all for openSUSE packages.

It would be very problematic. If only SLE version of %setup will understand the new %setup argument, say -G (skip translations update from upstream), how you can base SLE on openSUSE code base? Without -G it can fail due to possible error or non-standard gettext directory, with -G it will fail in openSUSE due to unimplemented option.

...

- Things may need tuning (e. g. for non-standard po directories)

See rpmlint suggestion above

How you would define, that gimp needs update of four po directories without breaking compatibility with a standard %setup command (see above)?

My view of this is, that when building SLE (which I guess is not done in the public OBS) the %setup macro could be extended to do this work automatically.

It cannot be done automatically. You need to specify: - that update is needed - which additional directories need to be processed - if upstream package contains gettext error, you need to apply patch before calling the script And for the collection tool: - define where to search for strings in the upstream SVN, CVS...

While openSUSE is being packaged and built in the public OBS, rpmlint can do the checks that are in place for this tool and generate a warning. The people involved in SLE would simply have to check the build result of packages that are of interest and fix them as appropriate. So once packages are copied for a new SLE version, there should be any errors.

When openSUSE Gold Master is released, its development continues as SLE. To prevent breaking of the system, only important fixes and minor changes can be accepted. It's impossible to change the whole build system behavior in this moment, and it's impossible to depend on repositories anywhere on the web, that may arbitrarily change.

Adding a BuildRequires and the needed line after %setup to each .spec file would, in my opinion, make the package less portable to other distros etc since it either have to be removed or one have to add %if checks.

Packages that are not part of any translation-update-upstream configuration file don't get translations merged from upstream. => You don't need to call translation-update-upstream. It is useful only for official openSUSE packages. If you want to recycle openSUSE package, you can simply use translation-update-upstream package as well. If you don't do it, then yes, you would need %if. As you already need %if for update-desktop-files, I see not a big problem there. By the way, gnome-patch-translation use the same %prep+BuildRequires approach. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Vincent Untz wrote:

Hey Stanislav,

Do we really want to manually update all spec files? It's not that hard if we only do that for GNOME packages, but if we want to have the complete distro using this, that's a different story. People will also forget to use this when adding new packages, I guess.

People have to define upstream resources in the tool configuration (e. g. upstream SVN server and interesting branches inside), otherwise the tool will not collect anything. This is a one-time update. Once it's done, you don't need to update po tarballs any more (the way we use in recent).

I didn't realize that earlier, but for SLE, once it's released, we don't rebuild packages, do we? (or well, I guess they're rebuilt with SP1, SP2, etc.) I would think we'd want to just provide updated lang packages?

Yes, the tool limits a it can provide translations. Submitting translation-update-upstream triggers package rebuild. Any attempt to update translation without package rebuild forces overriding of all strings provided by packages. It would require strict policy: - No po updates allowed in spec files. - No translation fixes allowed in spec files. - translation-update will become a "must have" package, as it contains translation fixes. If SLE packagers and users can live with these limitations, then it's possible to use the simpler way. It's impossible for SLE10/SLE11.

...

A: Such large change cannot be done in late beta or rc phase. It must be ready as soon as possible, only translation data file updates will have to be done in the rc phase.

Hrm, this sounds wrong :-) If it's not interesting for openSUSE, then, well, it just shouldn't go in openSUSE. So the question is "how can we make it interesting for openSUSE?". Since the packages won't be rebuilt once a version of openSUSE is released, I was thinking that all the logic you implemented could be used for updating the bundle lang packages.

bundle-lang is created from a particular language files after package build. You can move the merge there at cost of introduction of a strict po-patch policy and a bit higher process complexity. As bundle-lang packages don't cover the whole distro (and also version upgrade forces non-bundled lang package), you cannot prevent spec file editing at 100%. Translation-update package (not my -upstream one) does not need package rebuild at all, but it forces its strings overriding any fixes in packages. It would again require introduction of a strict po-patch policy. Without enforcing the strict po-patch policy, the tool was ready for SLE10 SP2, but quickly rejected: https://bugzilla.novell.com/show_bug.cgi?id=377971 (restricted) But maybe this simpler tool would be interesting for openSUSE. Updated strings are here and there are two ways to update: - during compilation: all our fixed are kept - as an extra package: all our fixes are overwritten by upstream

As much as I hate divergence from upstream... I also hate manual work. It sounds to me like we could have %setup look at some file to know if a package should be using this feature, and if it should how it should use it.

Yes, it is possible, but it would make hard time for people trying to build broken packages. Example: gtk2 in SLE11 has a broken distcheck => such %setup would fail. Now you can simply work-around this brokenness by commenting translation-update-upstream or gnome-patch-translation-prepare out. With a %setup reading a configuration, it will not be possible.

Okay. Stepping back a bit. Could we make something export the POT files of all packages, and then have your scripts run on those files, independently of the package build? This is non-intrusive for packages, and it would make it easy to build updated lang bundles.

No. pot files don't exist in general. translation-update-upstream source contains a pot collection tool that calls obs and gets all needed pot files. Note that gnome-patch-translation does a very similar job. translation-update-upstream is even smarter: It reviews all po files inside and packages only differences. It reduced the size of translation-update-upstream from 90MB to 3MB. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Vincent Untz writes:

Anyway, going back to the introduction of translation-update-upstream. I'd like to hear feedback from people outside of the GNOME team, since it will also be used for non-GNOME packages at some point, I guess. Personally, I'm really mixed with having to edit all spec files to add support for this, but if everybody is fine with it, then I guess it's a non-issue and we'll just do it this way..

I think that's fine. We do not need to edit all .specs at once. Does translation-update-upstream also support adding new languages? You must normally add the new language to the po/LINGUAS file. Hint to all package maintainers--you sometimes forget it while dropping in a *-po bundle from suse-i18n/lcn ;) -- Karl Eichwalder -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Karl Eichwalder wrote:

Vincent Untz writes:

...

Anyway, going back to the introduction of translation-update-upstream. I'd like to hear feedback from people outside of the GNOME team, since it will also be used for non-GNOME packages at some point, I guess. Personally, I'm really mixed with having to edit all spec files to add support for this, but if everybody is fine with it, then I guess it's a non-issue and we'll just do it this way..

I think that's fine. We do not need to edit all .specs at once.

And we need to edit it just once. Nowadays we edit it several times during the SLED release cycle to get translations updated. Vincent, I already did it for some packages. Here are pending submit requests with translation-update-upstream implementation. I will reset translation-update-upstream package soon after the test phase. It will be populated with a real content during the beta phase. alacarte: created request id 6927 atk: created request id 6929 at-spi: created request id 6930 brasero: created request id 6932 bug-buddy: created request id 6933 contact-lookup-applet: created request id 6934 dasher: created request id 6935 devhelp: created request id 6936 devilspie: created request id 6937 dia: created request id 6938 eel: created request id 6939 ekiga: created request id 6940 epiphany-extensions: created request id 6941 epiphany: created request id 6942 evince: created request id 6943 evolution-data-server: created request id 6945 evolution-webcal: created request id 6946 file-roller: created request id 6947 gcalctool: created request id 6948 gDesklets: created request id 6949 gdl: created request id 6950 gdm: created request id 6951 gedit: created request id 6952 gftp: created request id 6953 ghex: created request id 6954 glade3: created request id 6955 gnome-backgrounds: created request id 6956 gnome-blog: created request id 6957 gnome-bluetooth: created request id 6958 gnome-build: created request id 6959 gnome-commander: created request id 6960 gnome-desktop: created request id 6961 gnome-doc-utils: created request id 6962 gnomeicu: created request id 6963 gnome-keyring: created request id 6965 gnome-mag: created request id 6966 gnome-main-menu: created request id 6967 gnome-media: created request id 6968 gnome-mime-data: created request id 6969 gnome-mount: created request id 6970 gnome-netstatus: created request id 6971 gnome-nettool: created request id 6972 gnome-panel: created request id 6973 gnome-pilot: created request id 6974 gnome-power-manager: created request id 6975 gnome-screensaver: created request id 6976 gnome-themes-extras: created request id 6977 gnome-utils: created request id 6978 gnome-web-photo: created request id 6979 goffice: created request id 6980 goobox: created request id 6981 goocanvas: created request id 6982 gthumb: created request id 6983 gtkhtml2: created request id 6984 gtksourceview: created request id 6985 gvfs: created request id 6986 cheese: created request id 6987 libbonobo: created request id 6988 libbonoboui: created request id 6989 libbtctl: created request id 6990 libgnomecanvas: created request id 6991 libgnomecups: created request id 6992 libgnomekbd: created request id 6993 libgnome: created request id 6994 libgnomeprint: created request id 6995 libgnomeprintui: created request id 6996 libgnomeui: created request id 6997 libgsf: created request id 6998 libgtop: created request id 6999 memprof: created request id 7000 metacity: created request id 7001 nautilus-cd-burner: created request id 7002 nautilus: created request id 7003 nautilus-open-terminal: created request id 7004 nautilus-share: created request id 7005 nemiver: created request id 7006 NetworkManager: created request id 7007 pan: created request id 7008 pidgin: created request id 7009 PolicyKit-gnome: created request id 7010 sabayon: created request id 7011 seahorse: created request id 7012 swfdec-gnome: created request id 7013 totem-pl-parser: created request id 7014 vino: created request id 7015 vte: created request id 7016 xdg-user-dirs-gtk: created request id 7017 xchat-gnome: created request id 7018 yelp: created request id 7019 zenity: created request id 7020 evolution: created request id 7024 gnome-packagekit: created request id 7025 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Vincent Untz wrote in Tue 03/03 2009 at 14:35 +0100:

Le dimanche 22 février 2009, à 03:14 +0100, Vincent Untz a écrit :

...

Anyway, going back to the introduction of translation-update-upstream. I'd like to hear feedback from people outside of the GNOME team, since it will also be used for non-GNOME packages at some point, I guess. Personally, I'm really mixed with having to edit all spec files to add support for this, but if everybody is fine with it, then I guess it's a non-issue and we'll just do it this way..

There's been no feedback from non-GNOME packagers :/ I would have loved to get some, especially since it will probably affect non-GNOME packages at some point...

Stanislav: just one thing before I start accepting your submissions. For openSUSE, can you configure the tool to only look at latest upstream translations from the right branch?

It does never look to upstream during the compilation. It looks to translation-update-upstream package. When searching for strings, it should look at branch the current GNOME come from and all newer branches. As the merge is not a quick operation (several hours), and it may require manual action (fix strings in GNOME svn or skip buggy files), it's not started automatically. I will empty this package soon and start populating again after freeze, and the package will become dummy for now.

(we might want to do exceptions to this rule later, but right now, I don't think it makes sense for us to look at non-upstream translations)

If you find a package, where lookup to older branches makes sense, please let me know. I know just only about gnome-applets (we recycle old modem applet), but we migrated these strings to gnome-patch-translation there. Anyway, look at translation-update-upstream package source at *.tlst files with the current configuration. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Vincent Untz writes:

Hrm, this sounds wrong :-) If it's not interesting for openSUSE, then, well, it just shouldn't go in openSUSE. So the question is "how can we make it interesting for openSUSE?".

I can also help openSUSE. The time window is just smaller. During beta releases we have a package version freeze (b3?). From b3 to GA (RCx) ist usually lasts a month or more and during this period is still time to pull in translations from upstream. -- Karl Eichwalder -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Magnus Boman wrote:

On Sun, 2009-02-22 at 06:33 +0100, Karl Eichwalder wrote:

...

Vincent Untz writes:

...

Hrm, this sounds wrong :-) If it's not interesting for openSUSE, then, well, it just shouldn't go in openSUSE. So the question is "how can we make it interesting for openSUSE?".

I can also help openSUSE. The time window is just smaller. During beta releases we have a package version freeze (b3?). From b3 to GA (RCx) ist usually lasts a month or more and during this period is still time to pull in translations from upstream.

I know that I'm a bit stupid but, I still don't understand this. What translations would we add to openSUSE but not upstream?

September: Last update is done, versions are frozen. November: Upstream released new version with new translations. It's too late for version update. December: We'll collect translations from versions released in September to December and through translation-update-upstream populate to packages. End of December: Release of September version with translation quality of November version. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Karl Eichwalder wrote in Tue 02/24 2009 at 08:23 +0100:

Magnus Boman writes:

I think Stanislav answered this, but I'd like to add something more...

...

I know that I'm a bit stupid but, I still don't understand this. What translations would we add to openSUSE but not upstream?

Sometimes within lcn that's the openSUSE translation repository we translate upstream tools.

If we have our own translation maintained in lcn, then translation-update-upstream is over-complicated. It's intended for projects that have no trusted source of translation.

Often there is more than one upstream translation variant--for example, Debian or Ubuntu forks or our SLED or SLES translations done by the vendors.

translation-update-upstream allows to configure more sources with the "last one wins" policy. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org