Bug 97803 - gbuild: check that everything in instdir/ ends up packaged in the end
Summary: gbuild: check that everything in instdir/ ends up packaged in the end
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.0
Keywords: easyHack, skillScript
Depends on: 90753
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-12 16:09 UTC by DavidO
Modified: 2017-02-14 08:58 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description DavidO 2016-02-12 16:09:31 UTC
<mmeeks> mst__: would be nice it we had a check that everything in instdir/ ends up packaged in the end though (?)
<mmeeks> mst__: surely that's possible ?
<mmeeks> mst__: we lost the GL black-list from the packages ;-) so ...
<mst__> mmeeks: that would be possible, by requiring that every Package that is declared in a module must be registered with gb_Helper_register_packages_for_install or some dummy gb_Helper_register_packages_not_for_install, so you get an error if you forget it
Comment 1 DavidO 2016-02-12 16:15:39 UTC
<_david_> mst__, Can you suggest, how this dummy thing: gb_Helper_register_packages_not_for_install should look like?
mst__> _david_: see the way Library and Exectuable is registered, there is the same thing for NONE layer
<mst__> _david_: then on gb_Package_Package check that the thing has been registered somewhere
Comment 2 DavidO 2016-02-15 20:25:24 UTC
Adding the usual suspects gbuild hackers.
Comment 3 jani 2016-02-16 07:45:22 UTC
TO be an easyHack we need code pointers.
Comment 4 Björn Michaelsen 2016-02-25 19:41:05 UTC
not volunteering to mentor this one but "make packageinfo" as implemented as a PoC in solenv/gbuild/extensions/post_PackageInfo.mk is a code pointer as it shows all files that were properly registered in gbuild.
Comment 5 Commit Notification 2016-12-01 16:11:02 UTC
Matúš Kukan committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=39a4ca4072059b707a5368d8d215249e06258032

tdf#97803: gbuild: Check that resource targets are registered

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Matúš Kukan 2016-12-02 21:33:15 UTC
For packages, I've done https://gerrit.libreoffice.org/#/c/31571/ to "see" which are not auto-installed.
Often the files are installed another way, but at least 'sc_res_xml' looks suspicious.
Comment 7 Commit Notification 2016-12-07 15:43:37 UTC
Matúš Kukan committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4d5e5908b41308152698cfd769173c69cb3569d4

tdf#97803: gbuild: Check that every package is registered

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Matúš Kukan 2016-12-21 08:03:37 UTC
So, for 'sc_res_xml' there was bug 103332.

Anyway, there is not much more we can do here I'd say.
Any ideas?
I am closing this bug as resolved.