Summary: | KDE Serbian 14.12.1 contains conflicting files | ||
---|---|---|---|
Product: | [Translations] i18n | Reporter: | Daimonion <pejakm> |
Component: | sr | Assignee: | KDE translation into Serbian <Kde-i18n-sr> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aacid, caslav.ilic, scarpino |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/sysadmin/release-tools/2f483d7e2077aa105a37ca9e21db48f6587d033d | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: | Remove stuff inside pack_variants. |
Description
Daimonion
2015-01-25 13:11:33 UTC
And again it works on my end when with current release-tools (master), there are no extragear subdirectories in the pack... Please, be somehow more specific about which tarball you're speaking and which files next time so we don't have to spend our time in something you already know? Chusslove, you're using the wrong branch. Hm, yes, in Applications/14.12 branch it does not recursively call pack_lang for sublanguages, so does not remove stuff from them. A possibility would be to remove inside pack_variants*, as in attached patch. Created attachment 90666 [details]
Remove stuff inside pack_variants.
Git commit 2f483d7e2077aa105a37ca9e21db48f6587d033d by Albert Astals Cid, on behalf of Chusslove Illich (Часлав Илић). Committed on 26/01/2015 at 18:50. Pushed by aacid into branch 'Applications/14.12'. Remove stuff inside pack_variants. M +7 -1 create_log.py M +6 -0 pack_l10n.sh http://commits.kde.org/sysadmin/release-tools/2f483d7e2077aa105a37ca9e21db48f6587d033d This happens again: :: Starting full system upgrade... resolving dependencies... looking for conflicting packages... Package (1) Old Version New Version Net Change extra/kde-l10n-sr 14.12.2-1 14.12.3-2 0.00 MiB Total Installed Size: 64.73 MiB Net Upgrade Size: 0.00 MiB :: Proceed with installation? [Y/n] (1/1) checking keys in keyring [##########################################################################################] 100% (1/1) checking package integrity [##########################################################################################] 100% (1/1) loading package files [##########################################################################################] 100% (1/1) checking for file conflicts [##########################################################################################] 100% error: failed to commit transaction (conflicting files) kde-l10n-sr: /usr/share/locale/sr/LC_SCRIPTS/ki18n5/ki18n5.js exists in filesystem kde-l10n-sr: /usr/share/locale/sr/LC_SCRIPTS/ki18n5/trapnakron.pmap exists in filesystem kde-l10n-sr: /usr/share/locale/sr/LC_SCRIPTS/ki18n5/trapnakron.pmapc exists in filesystem kde-l10n-sr: /usr/share/locale/sr@ijekavian/LC_SCRIPTS/ki18n5/ki18n5.js exists in filesystem kde-l10n-sr: /usr/share/locale/sr@ijekavian/LC_SCRIPTS/ki18n5/trapnakron.pmap exists in filesystem kde-l10n-sr: /usr/share/locale/sr@ijekavian/LC_SCRIPTS/ki18n5/trapnakron.pmapc exists in filesystem kde-l10n-sr: /usr/share/locale/sr@ijekavianlatin/LC_SCRIPTS/ki18n5/ki18n5.js exists in filesystem kde-l10n-sr: /usr/share/locale/sr@ijekavianlatin/LC_SCRIPTS/ki18n5/trapnakron.pmap exists in filesystem kde-l10n-sr: /usr/share/locale/sr@ijekavianlatin/LC_SCRIPTS/ki18n5/trapnakron.pmapc exists in filesystem kde-l10n-sr: /usr/share/locale/sr@latin/LC_SCRIPTS/ki18n5/ki18n5.js exists in filesystem kde-l10n-sr: /usr/share/locale/sr@latin/LC_SCRIPTS/ki18n5/trapnakron.pmap exists in filesystem kde-l10n-sr: /usr/share/locale/sr@latin/LC_SCRIPTS/ki18n5/trapnakron.pmapc exists in filesystem Errors occurred, no packages were upgraded. Should I reopen or create another bug report? No idea what you mean with that. Can you point me to an issue in the tarballs KDE has produced? Albert, there's a file conflict between `ki18n` and `kde-l10n-sr` again. At least in Arch Linux. I have tried even versions of 15.04 of kde-l10-sr and 5.9 of ki18n. Conflicting files are: /usr/share/locale/sr/LC_SCRIPTS/ki18n5/ki18n5.js /usr/share/locale/sr/LC_SCRIPTS/ki18n5/trapnakron.pmap /usr/share/locale/sr/LC_SCRIPTS/ki18n5/trapnakron.pmapc /usr/share/locale/sr@ijekavian/LC_SCRIPTS/ki18n5/ki18n5.js /usr/share/locale/sr@ijekavian/LC_SCRIPTS/ki18n5/trapnakron.pmap /usr/share/locale/sr@ijekavian/LC_SCRIPTS/ki18n5/trapnakron.pmapc /usr/share/locale/sr@ijekavianlatin/LC_SCRIPTS/ki18n5/ki18n5.js /usr/share/locale/sr@ijekavianlatin/LC_SCRIPTS/ki18n5/trapnakron.pmap /usr/share/locale/sr@ijekavianlatin/LC_SCRIPTS/ki18n5/trapnakron.pmapc /usr/share/locale/sr@latin/LC_SCRIPTS/ki18n5/ki18n5.js /usr/share/locale/sr@latin/LC_SCRIPTS/ki18n5/trapnakron.pmap /usr/share/locale/sr@latin/LC_SCRIPTS/ki18n5/trapnakron.pmapc chusslove did you change what gets packaged into ki18n? Yes, at first it wasn't packing the scripts in ki18n, so someone noticed and we added that. So, these scripts should be part of ki18n package, and not in kde-l10n-sr. This problem is different though from the original report, in that it is not directly related to special subvariants of sr. It should also hit other languages which have some scripts in ki18n, like fi and gd. Although I do not see these scripts in kde-l10n-fi... Hm. How are 5/messages/<module>/<foo>.po in the pack selected for inclusion? Only the corresponding 5/scripts/<module>/<foo>/ should be included as well. Agreed it is a different bug, but since we're all here can you please prepare a patch so those are not distributed doubly? (In reply to Chusslove Illich from comment #11) > Although I do not see these scripts in kde-l10n-fi... Hm. > > How are 5/messages/<module>/<foo>.po in the pack selected for inclusion? > Only the corresponding 5/scripts/<module>/<foo>/ should be included as well. pack_l10n.sh in release-tools:Applications/15.04 first news i have of such a rule Ok, I was looking for the wrong thing. That script seemed to me as if it just packs everything and doesn't select anything, and that is what it does. Instead the problem is that there exists branches/stable/l10n-kf5/sr/scripts/frameworks, which it shouldn't. I removed it now (from all subvariants). Nothing to patch. |