Bug#771621: marked as done (libreoffice-common: ProductMajor in versionrc incorrect)
Your message dated Fri, 5 Dec 2014 10:17:00 +0100
with message-id <trinity-8d6431fd-2569-4467-a747-34765609d01e-1417771020531@3capp-gmx-bs10>
and subject line Aw: Bug#771621: libreoffice-common: ProductMajor in versionrc incorrect for 4.4 experimental packages
has caused the Debian Bug report #771621,
regarding libreoffice-common: ProductMajor in versionrc incorrect
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
771621: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771621
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libreoffice-common
Version: 1:4.4.0~beta1-2
Severity: normal
Looking at the packages currently in experimental,
/usr/lib/libreoffice/program/versionrc contains:
[Version]
AllLanguages=en-US af ar as ast be bg bn br bs ca ca-valencia cs cy da de dz el en-GB en-ZA eo es et eu fa fi fr ga gd gl gu he hi hr hu id is it ja ka kk km ko kmr-Latn lt lv mk mn ml mr nb ne nl nn nr nso oc om or pa-IN pl pt pt-BR ro ru rw si sk sl sr ss st sv ta te tg th tn tr ts ug uk uz ve vi xh zh-CN zh-TW zu qtz
BuildVersion=
buildid=40m0(Build:0)
ExtensionUpdateURL=http://updateexte.libreoffice.org/ExtensionUpdateService/check.Update
ProductMajor=40
ProductMinor=0
ReferenceOOoMajorMinor=3.4
UpdateID=LibreOfficeDev_4_en-US_af_ar_as_ast_be_bg_bn_br_bs_ca_ca-valencia_cs_cy_da_de_dz_el_en-GB_en-ZA_eo_es_et_eu_fa_fi_fr_ga_gd_gl_gu_he_hi_hr_hu_id_is_it_ja_ka_kk_km_ko_kmr-Latn_lt_lv_mk_mn_ml_mr_nb_ne_nl_nn_nr_nso_oc_om_or_pa-IN_pl_pt_pt-BR_ro_ru_rw_si_sk_sl_sr_ss_st_sv_ta_te_tg_th_tn_tr_ts_ug_uk_uz_ve_vi_xh_zh-CN_zh-TW_zu_qtz
UpdateURL=
UpdateUserAgent=<PRODUCT> (${buildid}; ${_OS}; ${_ARCH}; BundledLanguages=${AllLanguages})
Vendor=The Document Foundation/Debian
ProductMajor for 4.4.0 should be 440 not 40 (c.f. the packages in
testing and unstable which have 430 there).
Looking at the build log at
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=amd64&ver=1%3A4.4.0~beta1-2&stamp=1417158910
and searching for versionrc, I see two places which generate this file,
but the contents are different to that in the package in the archive -
they have the correct value for ProductMajor:
[build ECH] CustomTarget/instsetoo_native/setup/versionrc
/bin/bash: git: command not found
( \
echo '[Version]' \
&& echo 'AllLanguages=en-US' \
&& echo 'BuildVersion=' \
&& echo 'buildid=' \
&& echo 'ExtensionUpdateURL=http://updateexte.libreoffice.org/ExtensionUpdateService/check.Update' \
&& echo 'ProductMajor=440' \
&& echo 'ProductMinor=0' \
&& echo 'ReferenceOOoMajorMinor=4.1' \
&& echo 'UpdateID=LibreOfficeDev_4_en-US' \
&& echo 'UpdateURL=' \
&& echo 'UpdateUserAgent=<PRODUCT> (${buildid}; ${_OS}; ${_ARCH}; BundledLanguages=${AllLanguages})' \
&& echo 'Vendor=The Document Foundation/Debian' \
) > /«PKGBUILDDIR»/workdir/CustomTarget/instsetoo_native/setup/versionrc
Since libreoffice-common is arch all, the binary package in the archive
was built and uploaded by the maintainer. I'm wondering if there was
some issue with that build which caused either LIBO_VERSION_MINOR or
LIBO_VERSION_MICRO to be empty rather than 0.
Cheers,
Olly
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libreoffice-common depends on:
ii dpkg 1.17.22
ii libreoffice-style-galaxy [libreoffice-style-default] 1:4.4.0~beta1-2
ii ure 4.4.0~beta1-2
Versions of packages libreoffice-common recommends:
ii libexttextcat-data 3.4.4-1
ii python3-uno 1:4.4.0~beta1-2
ii xfonts-mathml 6
Versions of packages libreoffice-common suggests:
pn libreoffice-style-crystal <none>
pn libreoffice-style-hicontrast <none>
pn libreoffice-style-oxygen <none>
pn libreoffice-style-sifr <none>
pn libreoffice-style-tango <none>
Versions of packages python3-uno depends on:
ii libc6 2.19-13
ii libgcc1 1:4.9.2-4
ii libpython3.4 3.4.2-2
ii libreoffice-core 1:4.4.0~beta1-2
ii libstdc++6 4.9.2-4
ii python3 3.4.2-1
ii python3.4 3.4.2-2
ii uno-libs3 4.4.0~beta1-2
ii ure 4.4.0~beta1-2
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,
> lloconv uses it to pick whether to try to initialise "liblibreoffice" or
> "LibreOfficeKit". Or at least it did - I've just reworked it to pick
Err, wait? There was never a publically available liblibreoffice TTBOMK. So
one doesn't need to check for it.. I only saw it _internally_ in LOs build,
not installed anywhere.
(And even LibreOfficeKit is "hidden". IMHO it should be a proper .a/.so.X, but
anyway.)
> based on which hook function is present - that's a cleaner approach,
> though it does mean that the "shim" code is now greatly diverged from
> upstream. But that's only necessary until LO versions with
> LibreOfficeKit are ubiquitous.
Which (see above) is a given in stretch and not before :-)
> While the incorrectness of ProductMajor is no longer something I really
> care about, there is still something peculiar happening here which it
> would be good to try to get to the bottom of, i.e. that the binary
> package contains a different versionrc to the one which your buildlog
> shows should have gone into it.
True.
Closing this bug anyway.
Regards,
Rene
--- End Message ---
Reply to: