[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1073807: marked as done (windows binaries without source)

Your message dated Tue, 18 Jun 2024 22:34:13 +0200
with message-id <12d64b1c-fc67-4854-b365-14fd8d52e7a9@debian.org>
and subject line Re: Bug#1073807: windows binaries without source
has caused the Debian Bug report #1073807,
regarding windows binaries without source
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.)


-- 
1073807: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073807
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libreoffice
Severity: serious
User: paultag@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmaster@ftp-master.debian.org
thanks

There are some windows binaries in
testtools/source/cliversioning/version_libs/version_3_0_0.dll. The readme
notes that the files aren't reproducable given the current build env.

I'd usually spend a bit more time figuring out if we had source for it
and can find a way to maintain them in some form, but I don't think the
windows DLLs are used -- are they?

If it's possible to drop them that'd be ideal; if not, I'd love to make
sure we have (and maybe document in some form) where the source is for
those DLLs.

Thank you for all your work,
  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀               Paul Tagliamonte <paultag>
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋        Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- 
Hi,

Am 18.06.24 um 21:59 schrieb Paul Tagliamonte:

There are some windows binaries in
testtools/source/cliversioning/version_libs/version_3_0_0.dll.

Unused. We don't package the .net stuff

  The readme
notes that the files aren't reproducable given the current build env.
Yeah, it's old .dlls there to test whether they are compatible and the "policy files" (in my understanding .NETs way of "what is compatible with what, what is the version") work. 



I'd usually spend a bit more time figuring out if we had source for it
and can find a way to maintain them in some form,
The actual source is probably cli_ure. AFAICS there's no real code updates for cli_ure anyways since ags, so the actual code _is_ what is in cli_ure right now 

$ git diff libreoffice-7.4.7.2 libreoffice-24.8.0.0.beta1 cli_ure | diffstat
 CustomTarget_cli_ure_assemblies.mk |   61 +++++++++++++++++++++++----------------------------------- 
 Executable_climaker.mk             |    2 +
 Module_cli_ure.mk                  |    2 -
 qa/climaker/types.idl              |    8 -------
 source/climaker/climaker_app.cxx   |   17 +++++++---------
 source/climaker/climaker_emit.cxx  |  119 ++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------------- 
 source/climaker/climaker_share.h   |    4 +--
 source/uno_bridge/cli_bridge.cxx   |   22 ++++++++++-----------
 source/uno_bridge/cli_data.cxx     |    3 +-
 source/uno_bridge/cli_proxy.cxx    |    2 -
 10 files changed, 101 insertions(+), 139 deletions(-)
so those .dlls are not even touched since (here: stable). source/uno_bridge would be cli_uno_bridge.dll, no none of the "public library" .dlls tested above. 


rene@frodo:~/LibreOffice/git/master/cli_ure$ grep -ri policy *
CliLibrary_cli_basetypes.mk:$(eval $(call gb_CliLibrary_set_policy,cli_basetypes,$(CLI_BASETYPES_POLICY_ASSEMBLY),$(CLI_BASETYPES_POLICY_VERSION))) CliLibrary_cli_ure.mk:$(eval $(call gb_CliLibrary_set_policy,cli_ure,$(CLI_URE_POLICY_ASSEMBLY),$(CLI_URE_POLICY_VERSION))) CliNativeLibrary_cli_cppuhelper.mk:$(eval $(call gb_CliNativeLibrary_set_policy,cli_cppuhelper,$(CLI_CPPUHELPER_POLICY_ASSEMBLY),$(CLI_CPPUHELPER_POLICY_VERSION))) CliUnoApi_cli_uretypes.mk:$(eval $(call gb_CliUnoApi_set_policy,cli_uretypes,$(CLI_URETYPES_POLICY_ASSEMBLY),$(CLI_URETYPES_POLICY_VERSION))) 
[...]
version/version.txt:CLI_URETYPES_POLICY_VERSION=9.0.0.0
version/version.txt:CLI_URETYPES_POLICY_ASSEMBLY=policy.1.0.cli_uretypes
version/version.txt:CLI_BASETYPES_POLICY_VERSION=20.0.0.0
version/version.txt:CLI_BASETYPES_POLICY_ASSEMBLY=policy.1.0.cli_basetypes
version/version.txt:CLI_URE_POLICY_VERSION=23.0.0.0
version/version.txt:CLI_URE_POLICY_ASSEMBLY=policy.1.0.cli_ure
version/version.txt:CLI_CPPUHELPER_POLICY_VERSION=23.0.0.0
version/version.txt:CLI_CPPUHELPER_POLICY_ASSEMBLY=policy.1.0.cli_cppuhelper
version/incversions.txt:CLI_URETYPES_POLICY_VERSION
version/incversions.txt:CLI_BASETYPES_POLICY_VERSION
version/incversions.txt:CLI_URE_POLICY_VERSION
version/incversions.txt:CLI_CPPUHELPER_POLICY_VERSION

rene@frodo:~/LibreOffice/git/master/cli_ure$ git log version/version.txt
commit 17192ce5588f84192d1dd0d963622bda48566fdc
Author: Michael Stahl <mstahl@redhat.com>
Date:   Wed Aug 16 15:32:04 2017 +0200

    tdf#108709 cli_ure,unoil: bump CLI assembly versions for 5.4
    perl cli_ure/source/scripts/increment_version.pl cli_ure/version/version.txt cli_ure/version/incversions.txt temp.txt && mv temp.txt cli_ure/version/version.txt
    perl cli_ure/source/scripts/increment_version.pl unoil/climaker/version.txt unoil/climaker/incversions.txt temp.txt && mv temp.txt unoil/climaker/version.txt 

    Change-Id: Iaea028fc345d090317f7ebf128b683b4643a1093

commit e18655e47530f1e399cb546a6001fa0aa0f1873c
Author: Michael Meeks <michael.meeks@suse.com>
Date:   Wed Jun 27 17:37:30 2012 +0100

    re-base on ALv2 code.

5.4 ....


but I don't think the windows DLLs are used -- are they?


They aren't.



If it's possible to drop them that'd be ideal; if not, I'd love to make
sure we have (and maybe document in some form) where the source is for
those DLLs.
I don't really like to repackage it given I 'd loose the upstream signature...
Upstream is having a GSoc for "new" .NET stuff for 25.2, let's see how that complicates things, ideally cli_ure should be gone by then anyway. 


Closing with approval of submitter on IRC :)


Regards,


Rene

--- End Message ---
Reply to: