Jenkins user and sending mails in gerrit

[d . ostrovsky]

I just saw mail from Christian, where he is claiming that Jenkins user
can send mail to reviewers (I said the opposite), and is referencing
this mail from his mailbox:

X-Gerrit-ChangeURL: 

he got from Jenkins, where he is claiming he got the mail,
even though he is not the change owner.

That's correct, he is not the owner, Stephan Bergmann is the owner
of this change, but he is the author, because he performed the rebase
on patch set 1 of this change. So he is the uploader/committer of patch set 2.

When Jenkins is sending email, all reviewers are blocked, because
Jenkins user was granted DENY permission on EmailReviewers ACL,
so that Jenkins can only send email to authors of the change.
So the subtle term is who is considered to be an author of gerrit change?

Well, that's something very easy to find out, we are using open source tool,
and all we need is to read some code, and we are all developers here:

The gerrit code on branch 2.11 for ChangEmail.java is here:

gerrit-server/src/main/java/com/google/gerrit/server/mail/ChangeEmail.java

the relevant parts are here:

  public void setFrom(final Account.Id id) {
super.setFrom(id);

/** Is the from user in an email squelching group? */
final IdentifiedUser user =  args.identifiedUserFactory.create(id);
emailOnlyAuthors = !user.getCapabilities().canEmailReviewers();
  }

^^^ Here you see where canEmailReviewers ACL is evaluated and is stored
in boolean emailOnlyAuthors.

  protected void add(final RecipientType rt, final Account.Id to) {
if (! emailOnlyAuthors || authors.contains(to)) {
  super.add(rt, to);
}
  }

^^^ Here you see, the part where emailOnlyAuthors considered and in  
Jenkins case
this condition is always false. So the mail can be sent then and only  
then, when

the second condition evaluates to true: authors.contains(to)

/** Find all users who are authors of any part of this change. */
  protected Set getAuthors() {
Set authors = new HashSet<>();

authors.add(change.getOwner());
if (patchSet != null) {
  authors.add(patchSet.getUploader());
}
if (patchSetInfo != null) {
  if (patchSetInfo.getAuthor().getAccount() != null) {
authors.add(patchSetInfo.getAuthor().getAccount());
  }
  if (patchSetInfo.getCommitter().getAccount() != null) {
authors.add(patchSetInfo.getCommitter().getAccount());
  }
}
return authors;
  }

^^^ Here is the part about second condition from the if statement above.
Author set contains change owners and/or uploader/committer.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: How to solve the libreoffice build error?

[d . ostrovsky]

On Wed Jul 9 06:19:04 PDT 2014, Zhen Anddavid wrote:


I'm trying to build the LibreOffice 4.2.4.2 source.

[...]

--without-junit --disable-activex --disable-directx --enable-dbgutil


Remove --disable-activex and it should work.

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

BuildBot BUG

[d . ostrovsky]

On Thu Feb 27 08:49:36 PST 2014, Alexandre Vicenzi wrote:

Hi folks,

The buildbot is adding broken links in the history. It's aways  
showing this link: https://ci.libreoffice.org/job/buildbot/0

Can someone take a look?


Short story: we have found the problem and hope to solve it today.

Long story: Gerrit/Jenkins bridge is implemented as a new SSH command, that we
have contributed to Jenkins's external-jobs-plugin [1].

The pristine version of this command used return code from SSH command
to report build number back to buildbot/gerrit. During review process  
of our patch,
it was argued, that this was a bad idea, and it was changed to report  
over stdout

instead and returning always 0: [2].

We have never adjusted buildbot for that change of  
external-jobs-plugin's SSH command

and used our own home backed version of Jenkin's external-jobs-plugin.

Recently Jenkins machine had a reboot. During this reboot for some  
reasons that
i don't understand Jenkins was upgraded. And with it the core  
external-jobs-plugin.
Now, we have a mismatch between buildbot and external-jobs-plugin: the  
return code

is always 0, and stdout from that call is ignored.

[1]  
https://wiki.jenkins-ci.org/display/JENKINS/Monitoring+external+jobs#Monitoringexternaljobs-SubmitarunperCLI
[2]  
https://github.com/davido/gerrit-buildbot-plugin/blob/buildbot-2.5-plugin/src/main/java/org/libreoffice/ci/gerrit/buildbot/publisher/JenkinsLogPublisher.java


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: junit autogen error?

[d . ostrovsky]

On Tue Nov 19 00:11:49 PST 2013 Stephan Bergmann wrote:

The best fix probably is to use javac with -classpath junit.jar for  
the check.


You can use javap to check the existence of java classes in a JAR:

$javap -classpath /Users/davido/Downloads/junit4.11/junit-4.11.jar  
org.hamcrest.Matcher  /dev/null

$echo $?

$javap -classpath /Users/davido/Downloads/junit4.11/junit-4.11.jar  
org.hamcrest.Matcher2  /dev/null

$echo $?
1

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Can't access logerrit buildbot logs

[d . ostrovsky]

Zitat von Florian Effenberger flo...@documentfoundation.org:


Quick update from IRC:


thanks for fixing that. Buildbot-Log@Jenkins is reachable again.




[...]
[2:01pm] floeff: that being said, CI is still marked as testing VM  
in our intranet.


That's because Buildbot-logs deployment on VM4 was a temporary  
solution. The plan was to move that Jenkins instance to a new VM.



if that has changed, please notify hostmaster@tdf

Nope it didn't, unless we redefine VM4 as production VM.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Why not to use Gerrit patch set verification? -- was build failure in [build GAL] arrows

[d . ostrovsky]

On 17 June 2013, Matúš Kukan wrote:

Indeed, sorry for this, there was missing dependency hopefully fixed  
with [...]


it was broken for me too, while it was easy to fix with --without-galleries
option, i wonder why you don't use Gerrit?

Note:
mmeeks knows how to schedule a build now and is waiting that someone  
ask him to schedule a build ;-)

... and there are a lot of others on the IRC channel with the ACL too.

So every one has a choice now (until we have enough hardware to scale):

Scenario I:

1. upload a patch to Gerrit
2. ask for some one to schedule a build for it
Note: that step will be replaced with a simple click the Schedule button,
once we have a Schedule button on the Gerrit change screen (Current  
patch set action panel)
3. find out that it is broken on platform `foo` or `bar` without  
hurting other folks.
This is a tricky part here, but basically your change is on a virtual  
git branch in Gerrit,

and nobody cares that it is broken, compared to master
4. correct it
5. upload a new patch set to Gerrit
6. let re-schedule a new build for it (just click the Schedule button later)
7. submit the sane change to master

Scenario II:

1. commit your changes direct to master
2. break it
3. wait until other folks find it out and blame you
4. (hopefully) correct it (or may be not?)
5. write Indeed i broke it, sorry for this mail

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Different Gerrit workflows -- was Master branch now requires liborcus 0.5.0 or higher.

[d . ostrovsky]

Quoting Norbert Thiebaud nthieb...@gmail.com:


On Wed, Apr 24, 2013 at 2:02 AM, David Ostrovsky d.ostrov...@gmx.de wrote:

On Tue Apr 23 18:19:55 PDT 2013, Norbert Thiebaud wrote:


If you think that that list is missing someone(s) that are
very present on IRC and could help cover the request, I'm all ears.

can you please add Stephan and Lionel?


I have no objections adding stephan and lionel, please do.


done.
@Stephan, Lionel: you have the right now, don't screw it up ;-)


David. with your new patch having schedule/show queue would not mean
having get/put right ?


exactly! We would need to grant the new ACL to the BuildBots group  
first... and

as i said earlier, until we apply that patch, i do object to grant
the right to wider group of people: 15 core devs should do it for now.


that would be a great step in limiting the clusterfuck potential

definitely.
Please note: i've submitted the patch for master-buildbot (upcoming  
Gerrit 2.6 release) only.


David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Different Gerrit workflows

[d . ostrovsky]

On Tue Apr 23 05:43:20 PDT 2013, Stephan Bergmann wrote:


On 04/21/2013 01:04 PM, David Ostrovsky wrote:

So back to your use case: the content of your feature branch can be put
on Gerrit for *only* verification (not wasting days or weeks but only 2
hours) with *one* command:
git push logerrit your_branch:refs/for/master



But that does not trigger the actual verification builds, does it?

it does not.

My understanding is that one needs to ping a set of a few people who  
can actually trigger such builds.


Currently the members of three Gerrit groups can schedule the build:
BuildBotAdmin: 5 users
Administrators: 10 users
BuildBots: 1 (real) user

Because these groups are overlapping, we have 14 different users
that can currently schedule the build. Just ask on IRC. Have you tried?
(Or ask Norbert to add you to the BuildBotAdmin group.)

My gut feeling is that as long as there is no quick and direct way  
for a developer (with direct commit rights, say) to trigger those  
builds, that feature will be used significantly less often than it  
could be.


As Norbert explained on other thread, we can not do it without  
compromising the
buildbot set up for now: buildbot's whole interface depends currently  
on Gerrit's
global capability `View Queue`. That is due to the fact, that Gerrit  
Plugin API

doesn't support plugin's own capabilities (not yet).

As mentioned, the next steps are:
* put more hardware on buildbot
* extend the tool chain:
1/ visualize queue on Gerrit WebUI
2/ add Schedule button to core Gerrit Change screen (Current patch  
set action panel)


David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Trouble creating logerrit account

[d . ostrovsky]

On Thu Apr 18 08:53:05 PDT 2013, Wols Lists wrote:


How do I find out what name gerrit thinks I'm using, and how do I change it?


RTFM:
https://wiki.documentfoundation.org/Development/gerrit/setup#Setting_yourself_up_for_gerrit_-_the_easy_way

see (even with link):
2. You must set your username to match your freenode IRC nick (see  
'Username' in your gerrit account settings).


David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: claims of python unit test un-debugability considered somewhat exaggerated

[d . ostrovsky]

Quoting Michael Meeks michael.me...@suse.com:



Michael - as/when a python unit test fails - can we make the magic
environment variables that are listed include some debugging
instructions that include the py-bt detail etc. so that everything
needed is in the failure message ? when we're in the automatic trace
collection mode (I forget what env. var that is) do we dump the python
pieces as well ? Also - can we distribute / include / install the magic
that makes 'py-bt' work - not sure it works for me (on openSUSE - at
least a facile start gdb, type py-bt fails in spades ;-)


What we need here is a wiki page with detailed instructions how to set it up.
Volunteers? ;-)

David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: new gerrit-builds unit tests ...

[d . ostrovsky]

Quoting Norbert Thiebaud nthieb...@gmail.com:


On Thu, Apr 4, 2013 at 4:27 PM, David Ostrovsky d.ostrov...@gmx.de wrote:

* manual submit, currently only gerrit admin team can trigger it [4]

the limiting factor being windows that take ~2 hours
for a successful build, the 2 others take about 15 minutes.


you changed configure option [1] to '--disable-ccache' '--enable-pch'.
Any reason for that? Can we have ccache enabled again?

[1] https://ci.libreoffice.org/job/buildbot/465/consoleFull

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: gerrit's mail when adding a reviewer

[d . ostrovsky]

Quoting Stephan Bergmann sberg...@redhat.com:


On 03/28/2013 10:22 AM, Bjoern Michaelsen wrote:

On Wed, Mar 27, 2013 at 01:28:18PM +0100, Stephan Bergmann wrote:

Just noticed that when I add a reviewer to somebody else's change,
gerrit sends a mail taking on my identity (Stephan Bergmann (via
Code Review) ger...@gerrit.libreoffice.org) claiming I have
submitted a patch for review.  But I did not submit anything for
review, I merely invited somebody else to also review something.  I
find that confusing at least.


If you find a better wording, submit a patch for:

  
https://gerrit.libreoffice.org/gitweb?p=gerrit-etc.git;a=blob;f=mail/NewChange.vm;h=34af52f6a6c9a90fe9e9bb758d9c9721eea9bba0;hb=a60a0f9771a6d31c3e6c0c1b3745613264678b3f


But is that text only used when one adds an additional reviewer to  
an existing change, or is it also used for the initial mail when a  
new change is uploaded?


let code speak:

https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/java/com/google/gerrit/server/change/PostReviewers.java

in the method

private void postAdd(Change change, PostResult result)
mail is unconditionally sent using AddReviewerSender factory:

if (!added.isEmpty()) {
  AddReviewerSender cm;
[...]
  cm.send();
}

looking at it:

public class AddReviewerSender extends NewChangeSender

you can figure out, that it inherits from NewChangeSender:

https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/java/com/google/gerrit/server/mail/NewChangeSender.java

using that template:

@Override
  protected void formatChange() throws EmailException {
appendText(velocifyFile(NewChange.vm));
  }

and looking at RTFM it is even documented:

http://gerrit-documentation.googlecode.com/svn/Documentation/2.6/config-mail.html#_newchange_vm

If that is not what you expect, file a gerrit bug here:
https://code.google.com/p/gerrit/issues/list

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Trouble building master with ccache on Windows

[d . ostrovsky]

Quoting Kohei Yoshida kohei.yosh...@gmail.com:

On Tue, Mar 19, 2013 at 6:51 PM, David Ostrovsky  
d.ostrov...@idaia.de wrote:



Anyway gcc-wrapper should work with ccache enabled now:
https://gerrit.libreoffice.org/#/c/2857/


Yup, I confirm that it works now. :-)


After thinking about it i think we would better teach gcc-wrapper to
handle ccache case natively instead of stripping that information during
gcc-wrapper call.

Otherwise all gcc-wrapped external projects not aware of ccache.
And this is what we want to achieve in the first place.

@Peter: could you have a look?
To check in gcc-wrapper that REAL_CC and REAL_CXX could have
`ccache` prefixed and handle that case correspondingly?

Thanks
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: make error

[d . ostrovsky]

Quoting Michael Stahl mst...@redhat.com:



that is very odd, your javac does not understand -source and -target
parameters. [...]

that is not odd at all:
http://linux.die.net/man/1/gcj

the arguments are different there
-fsource
-ftarget

and because it is not the first time someone fails into it
http://nabble.documentfoundation.org/Make-help-td4035866.html
why not to add a check in configure and fail earlier?

But why do we still stick to 1.5 source and target version of bytecode anyway?

David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: rtl::OUString::compareToAscii is dangerous

[d . ostrovsky]

Quoting Stephan Bergmann sberg...@redhat.com:


On 03/19/2013 06:37 PM, Stephan Bergmann wrote:

I apologize in advance for any remaining occurrences that my build  
didn't catch.  (Where is the gerrit tinderbox trigger when one needs  
them?)

Currently only gerrit admins can schedule gerrit verification build.
But feel free to talk to Norbert to change that
(when you have the ACL it is `ssh buildbot schedule` command).
For now, just ping one from gerrit experts to schedule a build for specific
gerrit patch:

https://wiki.documentfoundation.org/FindTheExpert

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: make error

[d . ostrovsky]

Quoting Rene Engelhard r...@debian.org:


On Wed, Mar 20, 2013 at 12:22:59PM +0100, d.ostrov...@idaia.de wrote:
But why do we still stick to 1.5 source and target version of  
bytecode anyway?


Wven when we didn't, you need to use =1.6 (if you built with java7)

Which bring me to the question why? UNO java bridge doesn't support 1.7?


which would still keep the need for -target so this is (at least half)
a no-op for this specific issue.


But then still what is here the rule and what is here an exception?
The rule is we still must stick to -target 1.6.
And the exception is that one distro can only handle
-source 1.5  -target 1.5 for now. So sensible default would be to
only have -target 1.6 and have means to override that (in exception case.

David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH libreoffice-4-0] fdo#55814 SwDoc::UpdateExpFlds: hiding the last section may ...

[d . ostrovsky]

Hi,

Quoting Miklos Vajna (via Code Review) ger...@gerrit.libreoffice.org:


Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/2876

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/76/2876/1

fdo#55814 SwDoc::UpdateExpFlds: hiding the last section may be safe


thank you very much for fixing that regression!
Because writer usage severely restricted i would like to have that one  
on 3.6 branch too. Could you please submit it?


Thanks
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: cross-compiling and python

[d . ostrovsky]

On Tue Mar 5 Matus Kukan wrote:

But I don't think we need to get rid ourselves of python-build-time  
dependency.

Surely, at least on Linux and Windows, it is available.

+1

Mac OS X 10.7.5 here:
david@wizball python --version
Python 2.7.1

so, i would say, just drop that feature of using internal python
as python-build-time dependency and always require system python
to be installed and fail loudly if it is not the case.

David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: moz module gbuildification?

[d . ostrovsky]

On Mon Feb 25, Andras Timar wrote:


Did you try it on Windows with --enable-win-mozab-driver? For me the
build failed, moz headers were not in place when connectivity module
needed them.


should be fixed now.

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: issue building master: new dependency ?

[d . ostrovsky]

On Mon, Feb 25 Jean-Baptiste Faure wrote


I do not think so: I get the same error after a ./g pull -r and a
complete build (make clean  make dev-install)


i suspect this commit: 1baeaec3c98987fbedb6d02200fc4a95478adafb

MinGW seems also to suffer here:
https://ci.idaia.de/job/LO-Mingw64/154/consoleFull

with:
configure: WARNING: unrecognized options: --with-system-openssl

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

pending gbuild patches

[d . ostrovsky]

these pending gbuild patches [1], [2] move the location of main targets.
Which actions should be taken (other then making it compile on windows ;-)
prior to merging it, like uploading nightly build, odk publishing, etc.?

[1] https://gerrit.libreoffice.org/#/c/2242/
[2] https://gerrit.libreoffice.org/#/c/2288/

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

mingw build is currently broken

[d . ostrovsky]

Hi,

mingw build is seems to be broken on master:

[...]
[info  ALL] LinkTarget Library/libbasebmplo.so not defined: Assuming  
headers to be there!
2774  NEXT 
/local/home/tinderbox/master-mingw/solenv/gbuild/Package.mk:44: ***  
gb_Deliver_deliver: file does not exist in solver, and cannot be  
delivered:  
/local/home/tinderbox/master-mingw/solver/unxlngx6.pro/lib/libbasebmplo.so.   
Stop.


http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTERbrief-log=1360920613.1650

or more verbose:
https://ci.idaia.de/job/LO-Mingw64/136/console

Thanks
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: 2 commits - setup_native/CustomTarget_scripts.mk

[d . ostrovsky]

Hi Thorsten,

ah well, it was trying blind to fix it (hadn't access to a system with  
rpm package machinery),

but somehow i wasn't sure in the end... ;-)

David

Zitat von Thorsten Behrens t...@documentfoundation.org:


Hi David,

both the below fixes are needed for a build to pass here - what was
the reason for the revert?

David Ostrovsky wrote:

 setup_native/CustomTarget_scripts.mk |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 5f2cfb8dc537bd99399ba3942d0f685b6db6841b
Author: David Ostrovsky da...@ostrovsky.org
Date:   Sun Feb 10 13:45:06 2013 +0100

Revert replace '$' with '$%' as it was meant here

This reverts commit ef300e2dc3ac163cff14d659cc6e2154221c1a4e.

diff --git a/setup_native/CustomTarget_scripts.mk  
b/setup_native/CustomTarget_scripts.mk

index 10c7c0ba..f9edd90 100644
--- a/setup_native/CustomTarget_scripts.mk
+++ b/setup_native/CustomTarget_scripts.mk
@@ -26,7 +26,7 @@ $(scripts_WORKDIR)/fake-db-1.0-0.noarch.rpm:  
$(SRCDIR)/setup_native/scripts/fake

chmod g+w $(scripts_WORKDIR)/fake-db-root

 $(scripts_WORKDIR)/install:  
$(SRCDIR)/setup_native/scripts/install_linux.sh  
$(scripts_WORKDIR)/fake-db-1.0-0.noarch.rpm

-   $(PERL) -w $(SRCDIR)/setup_native/scripts/install_create.pl $? $@
+   $(PERL) -w $(SRCDIR)/setup_native/scripts/install_create.pl $ $@
chmod 775 $@

 $(scripts_WORKDIR)/uninstall:  
$(SRCDIR)/setup_native/scripts/uninstall_linux.sh

commit a92ae7280ebb4021c576f8604ead785ee0ba219e
Author: David Ostrovsky da...@ostrovsky.org
Date:   Sun Feb 10 13:44:56 2013 +0100

Revert fix fake-db-1.0-0.noarch.rpm: swap target with prerequisite

This reverts commit ef45fe7ff055692ec43bb5d6a438fb6ec29a9004.

diff --git a/setup_native/CustomTarget_scripts.mk  
b/setup_native/CustomTarget_scripts.mk

index 71ca7b5..10c7c0ba 100644
--- a/setup_native/CustomTarget_scripts.mk
+++ b/setup_native/CustomTarget_scripts.mk
@@ -22,7 +22,7 @@ $(eval $(call  
gb_CustomTarget_register_targets,setup_native/scripts,\
 $(scripts_WORKDIR)/fake-db-1.0-0.noarch.rpm:  
$(SRCDIR)/setup_native/scripts/fake-db.spec

mkdir -p $(scripts_WORKDIR)/fake-db-root
$(RPM) --define _builddir $(scripts_WORKDIR)/fake-db-root \
-   --define _rpmdir $(scripts_WORKDIR) -bb $
+   --define _rpmdir $(scripts_WORKDIR) -bb $@
chmod g+w $(scripts_WORKDIR)/fake-db-root

 $(scripts_WORKDIR)/install:  
$(SRCDIR)/setup_native/scripts/install_linux.sh  
$(scripts_WORKDIR)/fake-db-1.0-0.noarch.rpm

___


Cheers,

-- Thorsten




___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call, January 31, 2012

[d . ostrovsky]

[...]
   + Unix / LDAP addressbook support disappeared:
   + https://bugs.freedesktop.org/show_bug.cgi?id=57417
   + close that wontfix  release-note it ?


done: address book wizard dialog cleaned up, fdo#57417 closed wontfix,  
release notes updated:

https://wiki.documentfoundation.org/ReleaseNotes/4.0#Feature_removal_.2F_deprecation

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: fdo#51004: some progress and 10 years old bug pending

[d . ostrovsky]

Quoting Mat M m...@gmx.fr:


Le Wed, 21 Nov 2012 17:33:20 +0100, d.ostrov...@idaia.de a écrit:


Quoting Stephan Bergmann sberg...@redhat.com:


Further clean-up of all the Mozilla-related configure switches  
(--enable-mozilla, --disable-build-mozilla,  
--with-mozilla-toolkit, --with-system-mozilla,  
--with-mozilla-build) and config_host.mk.in variables  
(BUILD_MOZAB, DEFAULT_MOZILLA_TOOLKIT, MOZILLABUILD,  
MOZILLA_VRESION, MOZ_FLAVOUR, MOZ_INC, MOZ_LIB, MOZ_LIB_XPCOM,  
PREBUILD_MOZAB, SYSTEM_MOZILLA, WITH_MOZILLA), which should all  
now be relevant for Windows only, is highly appreciated.


the only option that would stay forever (even after dropping the  
whole mozilla mess from the build tree) is --with-mozilla-build. It  
is used for nss to provide some build tools. I suggest to rename  
this option to --with-nss-build or something like that (without  
name mozilla in it).




Am going for it.

thank you for helping out with this!


--enable-mozilla now means enable mozilla address book driver on windows
i suggest to rename it to --enable-mozab-driver-on-windows or  
something like that. It shouldn't be possible to enable this option on  
non-Windows platforms.



--with-mozilla-build will be renamed to --with-nss-build

may be --with-nss-toolbox or --with-nss-build-tools would be more clear?

--with-nss-build is required on windows if --enable-mozilla is on  
and --with-system-nss is off.

As Stephan pointed out these options are unrelated.
--with-nss-build (aka --with-nss-toolbox, aka --with-mozilla-build) is  
always mandatoy.



Other switches and related variables will be cleaned.


if i am not missing something, we could safely remove all other  
mozilla related options: we don't support system-mozilla here, even  
not on MinGW,
only in tree seamonkey is supported. And AFAIK we also don't use  
prebuilt seamonkey on Windows release machine, right?


So from all options, that Stephan mentioned above, only two should  
survive for now:


--with-nss-toolbox (aka --with-mozilla-build)
--enable-mozab-driver-on-windows (aka --enable-mozilla)

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: fdo#51004: some progress and 10 years old bug pending

[d . ostrovsky]

Quoting Stephan Bergmann sberg...@redhat.com:



Further clean-up of all the Mozilla-related configure switches  
(--enable-mozilla, --disable-build-mozilla, --with-mozilla-toolkit,  
--with-system-mozilla, --with-mozilla-build) and config_host.mk.in  
variables (BUILD_MOZAB, DEFAULT_MOZILLA_TOOLKIT, MOZILLABUILD,  
MOZILLA_VRESION, MOZ_FLAVOUR, MOZ_INC, MOZ_LIB, MOZ_LIB_XPCOM,  
PREBUILD_MOZAB, SYSTEM_MOZILLA, WITH_MOZILLA), which should all now  
be relevant for Windows only, is highly appreciated.


the only option that would stay forever (even after dropping the whole  
mozilla mess from the build tree) is --with-mozilla-build. It is used  
for nss to provide some build tools. I suggest to rename this option  
to --with-nss-build or something like that (without name mozilla in it).


David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: cppumaker crash ...

[d . ostrovsky]

Hi Michael,

Quoting Michael Meeks michael.me...@suse.com:



On Tue, 2012-11-13 at 11:49 +0100, Michael Stahl wrote:

I guess some include flags changed somewhere :-) still chasing.

boost was added to tail_build recently, so it could possibly be caused
by a missing dependency, i.e. something is built before boost and finds
the system boost headers.


It seems the problem was a set of missing:

$(eval $(call gb_StaticLibrary_use_unpacked,codemaker,boost))

Without those we would compile vs. the system boost and then (at some
stage) the real boost would be installed, and we'd then compile other
parts vs. that.


Lessons learned: when some external module is moved to tail_build (or  
gbuildified for that matter) one test schould be always done:  
uninstall the corresponding system lib and make clean LO build.


I extended the gbuild'ification documentation:
http://wiki.documentfoundation.org/Development/Build_System#Gbuildification_of_dmake_module

[...]
in case of external module:
* uninstall the corresponding system lib to make sure, that LO get  
built against

gbuild'ified module and not against system lib

Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: fdo#51004: some progress and 10 years old bug pending

[d . ostrovsky]

Quoting Stephan Bergmann sberg...@redhat.com:


On 11/09/2012 08:48 AM, David Ostrovsky wrote:

* deprecate moz shipping as it may be needed for some extensions. That
why Stephan reverted my patch:
don't compile moz module on all non windows platforms


Which commit are you talking about here?


this one: 903065dda1e574f4791ff40c31e39f14ba710424
which you have partially reverted (removing that section):
+dnl --enable-mozilla is supported only on Windows
+dnl ===
+
+if test $_os != WINNT ; then
+ if test $enable_mozilla = yes; then
+ AC_MSG_ERROR([--enable-mozilla is only available on Windows])
+ fi
+
+fi

My concern about it was (and still is), that someone in the wild still
compiles moz on non windows platform without actually using it in any way.

Regards
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Change in core[master]: restore --enable-symbols option again -- was FYI: Cleanup of debug options

[d . ostrovsky]

[bringing the discussion to ML as it related to other thread on this topic]

Quoting Lubos Lunák (via Code Review) ger...@gerrit.libreoffice.org:


Lubos Lunák has posted comments on this change.

Change subject: restore --enable-symbols option again
..

Patch Set 2: Do not submit

(2 inline comments)

With this patch there would be two independent ways to control  
whether -g is used, the other being ENABLE_DEBUGINFO_FOR, and  
moreover this breaks the other way, i.e. the selective debuginfo  
feature.



It seems to be not so easy to differentiate between two approaches:
* --enable-debug = which can be enhanced with selective debuginfo
* --enable-symbols (or whatever new name we want to give to that old option)

one option modifies optimization, another not
one option has impact on stl library, another not
one option can be extended with selective debuginfo, another not
[...]

So in this patch i started an attempt to follow the KISS principle and
make these approaches mutually exclusive: in the end it shouldn't be possible
to provide --enable-debug and --enable-symbols at once.
The result: one approach can not break another any more because they  
can not be

provided simultaneously.

It also might be a good idea to reconsider the symbols name,  
unless you want to repeatedly explain it to people who for some  
reason keep getting confused by all this stuff over and over again  
(it's a lot of fun I can assure you, and debug vs debug symbols  
is just asking for it).

will do. Do you have any preferences?
--with-profile-info
--with-backtrace-info

It possibly might make sense to fold --enable-symbols and  
--enable-selective-debuginfo in one option and functionality.

Let us divide it in two different use cases to minimize the hassle here.



Finally, I suggest the commit message just says that the option is  
back in order to avoid having to specify -g or similar manually,  
instead of the long list of claims you copied from the ML, as a  
number of those claims are questionable or just plain incorrect.

will do.




File configure.ac
Line 3374: AC_MSG_ERROR([--enable-debug cannot be used with  
--enable-symbols-only])

Wrong option name (2x).

will do.




File solenv/gbuild/gbuild.mk
Line 134: gb_SYMBOL := $(true)
This makes --enable-debug/dbgutil and --enable-symbols dependant,
even though your configure checks say that should not be used together.

yes, these options are mutually exclusive.


Or, put differently, this breaks the selective debuginfo functionality.

Why? gb_SYMBOL is used only in --enable-symbols case.
My intention was not to touch --enable-debug/dbgutil case at all.

Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: no functional TinderBox for master/3-7 full Windows builds

[d . ostrovsky]

Zitat von V Stuart Foote vstuart.fo...@utsa.edu:


I know every body's busy, but any chance that one of the three TinderBox's
for Windows master/3-7  can be brought back on line?

TB 16 doesn't build the full Windows bundle.

can't help you with tinderboxes, but i am doing irregularly windows builds
on master to test my LO work on these platforms:
* mingw (OpenSuSE)
* WindowsXP 32 bit with VC 2008 Express
* Windows 2008 Server 64 bit with VC 2010 Prof.

where you can download the full Windows bundles:
https://ci.idaia.de

For example you can download here the LO msi package from today morning
(it includes everything except binfilter, mozilla and some extensions):
https://ci.idaia.de/job/LO-Win2008-VC2010/4/

enjoy
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: no functional TinderBox for master/3-7 full Windows builds

[d . ostrovsky]

Quoting V Stuart Foote vstuart.fo...@utsa.edu:


Thanks David!

you are welcome!



So, I gave the Win2008  VC10 0build a go, but it seems like java  
support may not be in your build either. Or at least Tools -  
Options - Advanced  - Java Options is not detecting the installed  
JRE.


It is definitely not deactivated (with --disable-java),
so I configured it with jdk 7, 32 bit, see configure output:
https://ci.idaia.de/job/LO-Win2008-VC2010/4/consoleFull

[...]
checking the installed JDK... checked (JDK 1.7.0_09)
checking for target Java bytecode version... 1.7
checking for jawt lib name... jawt.lib
[...]

@Stephan am i missing something?

Regards
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

gbuildification of expat

[d . ostrovsky]

Hi,

during gbuildification of expat special treatment is needed to produce 64
bit libs for windows, because 64 bit expat is used there for 64 bit  
shell extensions:


https://gerrit.libreoffice.org/#/c/867/

To test it we need 64 bit OS and VS Professional.
While i tested gbuildified expat itself on windows server 2008 64 bit
and VS Prof. 2010, i am failing to compile the whole LO:

Error in cli_ure:
CliAssembly.mk:76 assembly version not set
I have no idea why, though.

I don't expect that someone going to review or test it
and am going to merge it in the next days.

Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ndtbl.cxx unused?

[d . ostrovsky]

Hi,

Quoting David Tardon dtar...@redhat.com:


Hi,

On Tue, Oct 23, 2012 at 10:05:48AM +0200, Miklos Vajna wrote:

Hi David,

On Tue, Oct 23, 2012 at 07:01:36AM +0200, David Tardon  
dtar...@redhat.com wrote:

 If a source file really contained only unused functions, it would likely
 have been found (and removed) with the help of callcatcher. Of course,
 that would not help if the source were not compiled at all (and we found
 such files on several occasions in the past)... I wonder if it would be
 possible to construct a (more or less) complete list of used source tree
 files from make dependencies; something that could be scripted and run
 periodically to ensure we are not accumulating unused cruft...

Not so easy, I think -- all OSX/Win-specific files are unused in a Linux
build, for example...


That is why I wrote possible, not easy .-)


Often the not easy problems are the most interesting ;-)
Typical distributed process with three steps here:

* first run it on all our main platforms (android, ios, macosx, mingw,  
win32, win64 (yes, we have x64 shell extensions), linux32, linux64)

* combine the results
* compare against source tree

Regards
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Error on rebuild in Windows cp: missing destination file operand after

[d . ostrovsky]

Hi,

Quoting David Tardon dtar...@redhat.com:


Basically it seems that in the command:
cp  $W/Extension/report-builder/root
 it's missing the first operand


It is a use case that nobody has ever tried before, because en-US is the
default language. The line comes from solenv/gbuild/ExtensionTarget.mk
and the missing argument(s) is a list of files based on $(gb_WITH_LANG),
but _without_ en-US. Since $(gb_WITH_LANG) contains _nothing but_ en-US
in your case, there are no files to copy...

the easiest way to sort this out would be to add a check in  
configure.in for that:

if --with-lang=en-US then fail or unset WITH_LANG, right?

Ciao
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Error on rebuild in Windows cp: missing destination file operand after

[d . ostrovsky]

Hi,

Quoting David Tardon dtar...@redhat.com:


Hi,

On Tue, Oct 16, 2012 at 11:38:28AM +0200, Stephan Bergmann wrote:

On 10/16/2012 11:14 AM, d.ostrov...@idaia.de wrote:
the easiest way to sort this out would be to add a check in configure.in
for that:
if --with-lang=en-US then fail or unset WITH_LANG, right?

No, the easiest thing should be to fix
solenv/gbuild/ExtensionTarget.mk.  I understand that the other David
is doing that.


Maybe not the easiest, but the most correct :-)

;-)
ah, well, if we are talking about the correct way ...
then we shouldn't play these games with such a construct
MODULE_FOO_LANGS := en-US $(filter-out en-US,$(gb_WITH_LANG))
any more but introduce a new variable gb_WITH_LANG_OR_DEFAULT
and use it in all places instead.

I mentioned it already in comment in readlicense_oo module during  
gbuildification ...

but didn't do it myself ;-)

http://cgit.freedesktop.org/libreoffice/core/tree/readlicense_oo/CustomTarget_readme.mk#n15

Regards
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: fdo#51004: some progress and 10 years old bug pending

[d . ostrovsky]

Hi Michael,

Quoting Michael Meeks michael.me...@suse.com:



Of course - it would be -lovely- to have a native C++ unit test in
dbaccess/qa/extras/ that we could use to do a few queries on a sample
mork file and add that to our regression test suite :-) having more
native-code dbaccess/ tests as a harness others can build around would
be really nice.


done: https://gerrit.libreoffice.org/#/c/841/

It seems to be the first cpp unit test in connectivity module
that does uno bootstraping and executes a SQL statement ;-)

I wasn't sure what would be the best way to differentiate between test
and production case, so i abused driver url...
It would be nice if someone could review it.

Thanks
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Beanshell and Javascript extensions not registered in master build

[d . ostrovsky]

Hi,

Quoting Alexander Thurgood alex.thurg...@gmail.com:


Le 07/10/12 22:59, Alex Thurgood a écrit :

I used the --enable-ext switches on both OSX and Linux 32bit - same
result, no functional beanshell or javascript extensions loaded, however
the build doesn't report any errors, even if I make the modules separately.

Anything to do with David's recent gbuildification changes ?


Could you please check that bsh.jar and js.jar are actually built and
delivered, i. e.:

make VERBOSE=true beanshell.clean
make VERBOSE=true beanshell

you should see copy bsh.jar to solenv.
If it is delievered how can i test these functional beanshell and  
javascript?

Did it work prior to gbuildification?

Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

gerrit is missing work in progress feature -- was Re: Change in core[master]: WORK IN PROGRESS gbuildification of jfreereport

[d . ostrovsky]

Quoting Norbert Thiebaud (via Code Review) ger...@gerrit.libreoffice.org:


Norbert Thiebaud has posted comments on this change.

Change subject: WORK IN PROGRESS gbuildification of jfreereport
..


Patch Set 1:

please to not use 'WORK IN PROGRESS' in the commit title
use a review -1/-2 + appropriate comment instead to indicate that
ditto for the TODO section is the commit message body

the risk here is that this kind of less than helpfull commit title  
end-up in the git repo... fixing the code is a matter of another  
patch.. but fixing the commit message of a commit after it has been  
push is not an option




as already discussed on IRC is review -1/-2 completely wrong here
(well from my point of view!).
Actualy gerrit is missing that WORK IN PROGRESS (WIP) feature.
With Draft no one can see it unless you add reviewer explicitly.

With WIP you want visibility, (possibly) earlier feedback and even  
tinderbox checks.


In fact if you think gerit is lack some feature, then first thing to check is
what the gerrit's power users did - openstack project:

open stack guys patched gerrit and added WIP feature to it!
We should probably just pick their gerrit version:

WIP patch, but still checked by CI Server:
https://review.openstack.org/#/c/14002/

WIP why: http://wiki.openstack.org/GerritWorkflow
[...]
If your code is not ready for review, click Work in Progress to  
indicate that
a reviewer does not need to review it for now. Note that the button is  
invisible

until you login the site.

WIP how: https://bugs.launchpad.net/openstack-ci/+bug/902953

WIP where:
https://github.com/openstack-ci/gerrit/commit/4212f6cb052661b7b36fe28e2776c1d769aa

Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: gerrit is missing work in progress feature -- was Re: Change in core[master]: WORK IN PROGRESS gbuildification of jfreereport

[d . ostrovsky]

Quoting Norbert Thiebaud nthieb...@gmail.com:


On Thu, Oct 4, 2012 at 4:30 AM,  d.ostrov...@idaia.de wrote:

as already discussed on IRC is review -1/-2 completely wrong here
(well from my point of view!).
Actualy gerrit is missing that WORK IN PROGRESS (WIP) feature.


Fine, when gerrit acquire that feature we will revisit that.


i am afraid this would never happen:
https://gerrit-review.googlesource.com/#/c/36091
https://gerrit-review.googlesource.com/#/c/36091/1//COMMIT_MSG

The way to go would be to stick with existing gerrit DRAFT feature
(don't forget to add reviewers there, otherwise no one can see it).
I will describe the DRAFT workflow on our wiki page.

Regards
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bundled saxon considered harmful

[d . ostrovsky]

Hi,

Quoting David Tardon dtar...@redhat.com:


It would be the committer's responsibility to build the extension and
continue maintaining the code (if there is anything to maintain there
:-) I suppose that unfortunate maintainer is going to be me, unless we
decide to put the code in a repo under libreoffice on fd.o; then
everyone of us would have access to it (but see the pros and cons in my
original email). Of course I welcome volunteers :-)


Why not use an gerrit project for it?
You can even replicate it to (read only) guthub repo (like openstack  
project) or where you want.


What you get is:
1. Proven patch review process
2. Commiters and approval rights are already established if they
inherited from core project (or could be project based)
3. Low entry barrier for new contributors
4. Best visibility and transparency
... just keep reading Norbert's FAQs here
http://lists.freedesktop.org/archives/libreoffice/2012-June/033872.html
to find more reasons.

While i am aware that not all our devs are gerrit funs,
i would go even further and suggest to open gerrit for other
LO extensions and non core libraries and tools as well
like cppunit, cmis, mdds, etc.

wikimedia already doing just that (and many other too, including  
gerrit itself):

see project names https://gerrit.wikimedia.org/r/#/q/status:open,n,z

Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bundled saxon considered harmful

[d . ostrovsky]

Hi Norbert,

Quoting Norbert Thiebaud nthieb...@gmail.com:


On Thu, Oct 4, 2012 at 7:37 AM,  d.ostrov...@idaia.de wrote:

Hi,

Quoting David Tardon dtar...@redhat.com:


It would be the committer's responsibility to build the extension and
continue maintaining the code (if there is anything to maintain there
:-) I suppose that unfortunate maintainer is going to be me, unless we
decide to put the code in a repo under libreoffice on fd.o; then
everyone of us would have access to it (but see the pros and cons in my
original email). Of course I welcome volunteers :-)


Why not use an gerrit project for it?


david, you missed the original email from david tardon, specifically  
that part:


1. a repo on fd.o under libreoffice
[...]
CONS:
* it is somehow tied with libreoffice, so people might expect us to put
  the extension into the install sets (which is what I wanted to avoid in
  the first place :-)

No, i didn't miss it. The (read only) repository is located on guthub,  
or gitosis or ... While it is replicated from gerrit.libreoffice.org  
there, this and other extensions hosted there are *not* bundled into  
LO's installation

set per definition (it is documented, underlined, bold and blinking
for that matter).


Of course I welcome volunteers :-)
Another advantage if it is hosted on gerrit: i am going to contribute  
to it ;-)


Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bundled saxon considered harmful

[d . ostrovsky]

Hi,

Quoting David Tardon dtar...@redhat.com:


Note that it is possible it will never be needed by anyone. I have
already said I do not know of any existing XSLT filter that uses XSLT
2.0. But there was demand for it back in OO.o times and it was one of
the reasons for switch from xerces to saxon. Because I cannot prove such
filter does not exist, I did not just drop the code, but put it into an
extension, so we do not inconvenience people needlessly.


It sounds very suspiciously like YAGNI rule [1] candidate to me, in  
wich case we should probably just kill it or like Michael Stahl put it  
[2] ... kill it with fire.


[1] http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it
[2]  
http://lists.freedesktop.org/archives/libreoffice/2012-September/038983.html


Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Drop support for Java 5?

[d . ostrovsky]

Hi Michael,

Zitat von Michael Meeks michael.me...@suse.com:



On Tue, 2012-10-02 at 14:53 +0200, Michael Stahl wrote:

 Mac OSX 10.4 only comes with 1.5.

 what about to drop support for Mac OS X 10.4 then?

that is on the LO4 todo list :)


Worth adding to the wiki page so we don't forget I imagine:

http://wiki.documentfoundation.org/Development/LibreOffice4


done:

https://wiki.documentfoundation.org/Development/LibreOffice4#Discontinued_support_for_obsolete_platforms_and_libraries

Ciao
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: --with-lang build failure

[d . ostrovsky]

Quoting Andras Timar tima...@gmail.com:



I had the same problem today. In
workdir\unxlngx6.pro\CustomTarget\translations\translate\sdf-l10n\
directory language sdf files were 0 bytes long. When I rebuilt
translations module alone, the problem disappeared. I suspect that it
will come back after make clean.


Last weekend 4 modules were moved to tail_build:
readlicense_oo, l10ntools, clucene and translations.

Apparently some dependencies (to translations) are still missing.
Here is an example of such a dependency in readlicense_oo module:
http://cgit.freedesktop.org/libreoffice/core/tree/readlicense_oo/CustomTarget_readme.mk#n39

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

new mork driver: regex match logic is required

[d . ostrovsky]

Hi,

regex match logic is required in the new mork driver.
In the old one it was done in xpcom seamonkey backend.

For now it is not implemented:
http://cgit.freedesktop.org/libreoffice/core/tree/connectivity/source/drivers/mork/MQueryHelper.cxx#n330

Any help (or patch) is highly appreciated ;-)

Ciao
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

preventing gerrit changes from being merged

[d . ostrovsky]

Hi,

recently some gerrit changes were accidentally merged into master  
through gerrit UI.
While there are ways to prevent it, like voting -2 for a change or  
prefixing the
commit message with work in progress, please don't merge or  
something like that,

I want to share with you the gerrit way to achieve that: draft queue feature.

Default queue in gerrit is publish queue. All changes are submitted to  
it per default.
Recently draft queue was introduced in gerrit. If you submit a change  
to draft queue it

cannot be merged. That change must be first promoted to publish queue.

To use draft queue, all you need is to pass -D switch to git-review:
git-review -D
If you don't use git-review, you can specify the draft queue on command line:
git push logerrit master:refs/draft/master
(or whatever branch you need).

When you are ready you can promote your change to publish queue with  
UI or with command line:

ssh logerrit gerrit review --publish COMMIT | CHANGEID

See https://gerrit.libreoffice.org/Documentation/cmd-review.html for  
more details.


Ciao
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: sal/config.g sal/types.h and sal/osl/rtl includes in general

[d . ostrovsky]

Quoting Stephan Bergmann sberg...@redhat.com:


On 09/18/2012 12:14 AM, Norbert Thiebaud wrote:
[...]
for 2/
I propose to create a file 'lo.h', in solenv/inc/ for now... and start
to bring all source code in conformance... [...]


I'm not sure such a lo.h combining inclusion of multiple other  
header files would be a good idea.  With the constant flux across  
our code base, I think aiming at precise, minimal includes is a  
better approach, as it helps achieving minimal rebuilds.

+1 for that.
Was spending hours (!) yesterday during rebuilds with total ccache  
misses because of recent header changes.


In generall to make the life of (casual) contributor as easy as  
possible is the highest priority in open source
environment. Not everybody posses the up to date hardware and/or time.  
Of topic but in the same context - achieving minimal rebuilds -  
still urgently missing these build options:


--disable-all-tests (or new build target make  
dev-instal-without-unit-tests for that matter)
yes i know you don't want it, and that project is not a debate club,  
and someone must decide and you did.

Well I accept your decision ... and disagree.

--disable-cve-tests
CVE unit tests still prevent me from be able to compile LO on windows  
with activated antivirus. Someone wanted implement it? Who was it? Mat  
M. or me? ;-) Note: once we have --disable-all-tests we probably don't  
need it.


--enable-apps-only=base sw
if someone is working on one or two apps there is no reason to rebuild  
the whole suite all the time.


Ciao
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: sal/config.g sal/types.h and sal/osl/rtl includes in general

[d . ostrovsky]

Hi Noel,

Quoting Noel Grandin n...@peralex.com:



On 2012-09-19 15:27, d.ostrov...@idaia.de wrote:


--disable-cve-tests
CVE unit tests still prevent me from be able to compile LO on  
windows with activated antivirus. Someone wanted implement it? Who  
was it? Mat M. or me? ;-) Note: once we have --disable-all-tests we  
probably don't need it.


This is very easy to sort out - go into your antivirus tool, and  
specifically exclude your LO directory structure. I do it on all my  
build machines.
unfortunally not an option for me. Have you ever thought about  
enterprise environment,

where antivirus is running with admin rights and normal user not?
You would fail with your first suggestion: go into your antivirus  
tool: no rights there ...


Ciao
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: feature/gbuild_ure needs testing

[d . ostrovsky]

Hi David,

Quoting David Tardon dtar...@redhat.com:

[...]


I do not suppose I am going to get any more
testers for the branch, so I am going to merge it to master in a couple
of days (most probably on Saturday). Thanks everyone involved
(especially Matus) for testing!


clean build on mingw (OpenSUSE 12.1) was sucessful:
https://ci.idaia.de/job/LO-Mingw64/88/
https://ci.idaia.de/job/LO-Mingw64/88/console

Ciao
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

fdo#51004: some progress and 10 years old bug pending

[d . ostrovsky]

Hi,

there is some progress with that issue:
https://bugs.freedesktop.org/show_bug.cgi?id=51004

Note: the situation on debian/ubuntu is really serious, because they  
are not shipping somehow strange hacked mozilla version at all.


You can find some funny comments on that 10 year old bug:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/93546
The last one is mine.

Any chance to address it in 3.7? The plan is (Fridrich, Stephan and  
Michael Stahl agreed upon and get blame if it goes wrong ;-)


1. Change the implementation on feature/mork branch to still depend on  
mozilla on windows. (Currently mozilla stripped there for all  
platforms completely).

2. Merge that feature branch to master (this week?).
3. Fix some minor issues.
4. Ask hackers to play with it (i have been told on IRC, that hackers  
only tend to play with some experimental features if they find it on  
master ;-)
4. Provide beta builds for QA Team to test it (the problem is that i  
don't really know what is still missing, besides todos that described  
in bz above).


We have one problem with that approach: other linux distros that are  
shipping mozilla mozab driver can experience less features or less  
quality with that new implementation. But ... no risk, no fun ;-)


Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: git review

[d . ostrovsky]

Quoting Norbert Thiebaud nthieb...@gmail.com:


On Thu, Aug 9, 2012 at 7:04 AM, Bjoern Michaelsen


Thinking a bit about this, another possibility would be to do with  
git-review

as we do with other external stuff:
Downloading and installing a local copy in ./download. That would  
ensure it

to be universally available and be up to date.


I know that michael disagree with me on that, but I prefer dev-tools
to be in ...  dev-tools.git
one can install it as he see fit. and you get the version you
want/need regardless where you are in the source tree...


Well to put it in dev-tool is much less painfull as to put it elsewhere.
Note this tool must be in your PATH! For all branches.
And even if you switch the branches and no matter what your current  
directory is,

you must be able to say:
git review --dry-run

that it.
But who is the person who will put it in dev-tools once and update it  
all the time?

(Last time i contributed to git-review was today morning).
But even if that person (not me) or some cron jobs continuously  
synchronize it, the user must still update it.


So the user must now periodically update dev-tool to get the fresh version
of git-review? But then what is the difference to say git pull  
dev-tools/git-review or


sudo apt-get update upgrade (place here your distro command)
or (*)
sudo pip install git-review
sudo pip install --upgrade git-review
sudo pip uninstall git-review

(*) http://www.pip-installer.org/en/latest/index.html

Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: mingw build broken

[d . ostrovsky]

Hey Kendy,

thank you for your response.
Yeah, my wine-* packages were outdated (1.4.*, we could check it in  
configure). After upgrading winegcc is working again, and after ccache  
-C

(@David tnank you for that hint) LO even compiles, but

... cd /tmp/xfUNKMLKsY_temp.11871; tar -cf - . | gzip   
/home/david/numpty/workspace/LO-Mingw32/instsetoo_native/wntgcci.pro/LibreOffice_Dev_SDK/archive/install/en-US_inprogress/LibO-Dev-SDK_3.7.0.0.alpha0_Win_x86_install-arc_en-US.tar.gz  
...


where is the expected msi package?
Or do i have to provide some extra configure parameter for that?

Regards
David

Quoting Jan Holesovsky ke...@suse.cz:


Hi David,

On 2012-07-28 at 23:20 +0200, David Ostrovsky wrote:


here is the whole truth (CC to David, because he is the second one, who
knows what going on on mingw world ;-):

http://pastebin.com/96xS1WHt

Should i file the bug request on winehq project?


No idea - it still might be some misconfiguration that is not covered by
the configure checks, or something, no real idea :-(  It builds for me
here, but of course, I first got it to build, and then tried hard to
reproduce my fails, and cover them in configure, but apparently I must
have had some pre-configured things, or something.

As you asked on the irc:


rpm -qf /usr/lib/wine/libkernel32.def

wine-devel-1.5.9-178.1
wine-devel-32bit-1.5.9-178.1

The best might be to extend the winegcc check so that it we do that only
when we are trying to build the msi; OTOH we should default to that
ASAP...

Sorry for the trouble :-(,
Kendy





___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] set WINEGCC only when cross compiling

[d . ostrovsky]

Hey Kendy,

np, i had to do something, because my (native) build on Ubuntu was  
failing with the error: building msi package failed ;-)
it turned out that msi was trying to build, because WINEGCC was  
unconditionally set during configuration process.


That why i fixed it in that way. I hope, that your fix is even better ;-)

Regards
David

Zitat von Jan Holesovsky ke...@suse.cz:


Hi David,

On 2012-07-26 at 18:07 +, Gerrit wrote:


Change subject: set WINEGCC only when cross compiling


I am sorry, but I had to revert this change, this results in improperly
set cross-compilation environment.  The winegcc is needed in the 'build'
part of the configuration which knows nothing of actually being part of
cross-compilation.  I believe the following sorts it out for everyone:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=06b9b2148e6f261e34637ae5797a5f274635a628

All the best,
Kendy

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice




___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Gerrit: branch libreoffice-3-6-0 is out of sync -- was Re: [REVIEW][3-6-0] Re: [PATCH] Change in core[libreoffice-3-6]: fdo#39812: Writer: fix collapsing merged table border painti...

[d . ostrovsky]

Hi Michael,

Quoting Michael Stahl mst...@redhat.com:


i'm trying to push this to gerrit libreoffice-3-6-0, but git-review
warns me that it wants to push not 1 but ~10 patches; apparently the
libreoffice-3-6-0 branch on gerrit is not automatically updated?


indeed, as you can see here
http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/gerritbot/syncgerrit
libreoffice-3-6-0 branch is still missing:
[...]
branches['core']  = ['master', 'libreoffice-3-5',  
'libreoffice-3-5-5', 'libreoffice-3-6']

[...]

I would suggest to file a bug to ger...@otrs.documentfoundation.org.

Regards
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [libreoffice-projects] [ANN] Please use Gerrit from now on for Patch Review

[d . ostrovsky]

Zitat von Bjoern Michaelsen bjoern.michael...@canonical.com:



Something like:
- a short dialy digest of changes to keep reviewers in the loop
- _one_ mail once a change goes in with all the comments/revisions and
  back-and-forth for this change in context in it

or something completely different? We might get rid of the first (or  
only send

it if there are changes untouched for more than a day) later or never do the
second or tweak all of that, but for now we need a sensible start ;)


Sensible start would be:
1. set up a new ML: Libreoffice-gerrit (analogical to LO-COMMIT ML)
2. subscribe dev ML to get a daily digest from the 1. (or generate the  
digest manually).

3. set up IRC Bot to #libreoffice channel to notificate about gerrit events.

Regards
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: feature/gbuild_merge needs testing

[d . ostrovsky]

Hi Noel,

thank you for your help!


[ build ECH ] CustomTarget/testtools/bridgetest/bridgetest_server.bat
make[2]: *** No rule to make target  
`D:/workdir/wntmsci12.pro/CustomTarget/testtools/bridgetest/bridgetest_javaserver.bat', needed by `D:/workdir/wntmsci12.pro/CustomTarget/testtools/bridgetest.done'.   
Stop.


in testtools module 4 batch files are created.
These echo targets were more or less direct migrated from dmake makefile.
could you please retry it with
make verbose=t testtools

Or may be you can retry it on the master where testtools module is  
still built with dmake.

What's the difference?

Thanks
David

Zitat von Noel Grandin n...@peralex.com:


Build error log attached for a cygwin build (i.e. on Windows).

On 2012-05-25 13:28, David Tardon wrote:

Hi all,

I pushed feature/gbuild_merge branch that merges 4 gbuild-related
branches rebased on current (~3 days old) master. It seems it still
builds fine on linux and mingw, but I would appreciate more testing. The
current plan is to get it back into master before 3.6 feature freeze,
which do not leave much time (Sorry it took me so much time to do the
merge, but there were a lot of changes, e.g., the recent TDE
integration, and feature/gbuild_connectivity was really old (created in
December or so)).

The branch contains conversion of 5 modules to gbuild: connectivity,
reportbuilder, scp2, shell and testtools. Conversion of scp2 is testable
by http://dtardon.fedorapeople.org/libreoffice/test-conversion.sh , so
it might be a good idea to run

./test-conversion.sh -b
# make clean
make

(The script will build all up to (and including) scp2 at point just
before the conversion of scp2, then build scp2 again at the tip of the
branch and compare the created install scripts.)

The number of modules newly added to tail_build is not as good as I
expected--only 9, if I counted correctly. On the other side all the
really big ones are there already :-) There is experimental branch
feature/tail_build that adds 19 more, but it requires a change to
build.pl, so I do not intend to push it into 3.6 . Of course, if people
who actually know something about the build.pl script look at commit
726ac115a981567b3f41613d0e0163bd010e6b17 and tell me that I am not a
total idiot, or even that it might work at the right phase of moon, I
can be convinced otherwise :-)

Another thing that I should mention is that the gbuild modules seem to
take really good care of dependencies: I only had to add two when
testing build of feature/tail_build .

At the end, an anecdotical evidence about how far we progressed into
gbuild land: the move of gtk/kde file pickers from fpicker to vcl
introduced a dependency loop, because the pickers in vcl depend on
headers from fpicker, but fpicker already (indirectly) depends on vcl.

make cmd cmd='cd vcl; build.pl --all'
...

Fatal error:
test depends on:  vcl
fpicker depends on:  svtools
toolkit depends on:  test vcl
svtools depends on:  test toolkit
vcl depends on:  fpicker
ERROR: There are dead or circular dependencies

Nobody has noticed that (at least I do not remember any thread on the
mailing list regarding such a thing), because both modules are already
in tail_build, so make still works. Incidentally, thanks to Bjoern's
changes to build.pl, make vcl.all works too (or nearly works--it seems
to always break on the last module. That does not bother me enough to
look into that horrible perl script for possible cause, though).

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice




Disclaimer: http://www.peralex.com/disclaimer.html





___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: building master against mac 10.7.4 using the 10.6 SDK

[d . ostrovsky]

Hej Christian,

Zitat von Christian Lohmaier lohmaier+libreoff...@googlemail.com:


HI Jonathan, *,

On Tue, May 22, 2012 at 11:39 AM, Jonathan Aquilina
eagles051...@gmail.com wrote:


I am trying to build master on my mac using clang.


The topic doesn't make any sense, you cannot build explicitly for a
newer version of Mac OSX using an older version of the SDK.

you can try to build on 10.7 against the 10.6SDK - and that build will
also run on 10.7.


CC_FOR_BUILD=ccache clang -arch x86_64 -mmacosx-version-min=10.6
CXX_FOR_BUILD=ccache clang++ -arch x86_64 -mmacosx-version-min=10.6
--with-build-platform-configure-options=
--with-macosx-version-min-required=10.6
--with-macosx-sdk=10.6
--disable-mozilla
--without-doxygen

only modification i made was to build for 64bit.


only modification You're a funny one...


have you forgot to place a smily here ;-)


* Neither is building against something else than the 10.4SDK
something that has been tested
* and even less so is creating a 64bit build on Mac.


I was not aware of this too. I saw it first during my last
rtlootstrap.mk patch

cat configure.in
[...]
darwin*)
[...]
i*86|x86_64)
CPU=I
CPUNAME=INTEL
RTL_ARCH=x86
[...]

I could look at 64-bit MacOSX build, if i had mac resources ...
Or may be you (or your thinderbox) can compile for me and I would try  
to do it without mac ;-)?


Ciao
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Branch 'feature/gbuild_testtools' - win mac test request

[d . ostrovsky]

Zitat von Norbert Thiebaud nthieb...@gmail.com:

On Mon, May 21, 2012 at 1:52 AM, David Ostrovsky  
david.ostrov...@gmx.de wrote:

Hi,

with help of David T. Stephan and Matúš this branch can be merged to master.
It would be really nice, if some of you with win  mac could test it.
If we do not hear anything withing 2 days we would merge it to master anyway
;-)


As I mentionned to dtardon earlier,
due to the number of such gebuild feature branch (half a dozen or so),
it would be nice to merge them all on a 'meta' feature branch where
merge conflict, and otehr kink can be ironed-out and tested and all
platforms.. and _then_ get it to master.


Another possibility would be to do reviewing, verification and  
hardening on gerrit. Unfortunately gerrit was outdating last time i  
tried to push to it,

and you and Bjorn were busy at UDC ;-)

When can we really use it with:
git push gerrit HEAD:refs/for/master
or even push to gerrit before merge to master:
git push gerrit HEAD:refs/for/feature/gbuild_testtools

Note: I'm aware that at this time no push from gerrit to fdo git  
repository is possible. But anybody could review and pull from gerrit  
and feed their tinderboxes (or whatever CI build server they use) with  
it.


Thanks
David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] make, use mixed paths on cygwin, remove ugly paths conversion

[d . ostrovsky]

Hi,

+1 for this.
This simplify enormously the whole build.
The only question is, can we require, that all Windows build machines  
have make 3.82 installed?


Ciao
David

Zitat von Noel Grandin n...@peralex.com:


Hi

Any chance we can get this in so I can get my tinderbox running on a  
RAM-Drive?

I can confirm it works on my tinderbox at least.

Regards, Noel Grandin.

On 2012-05-06 20:57, Matú? Kukan wrote:

Hello,

These patches allow us to get rid of path conversions in makefiles by
using cygpath -m format.
But this only works with make 3.82, so configure is also changed.
(Only for cygwin)
There are only few exceptions where we need cygpath -u format.

I am not sure if we want this now or later. (after libreoffice-3-6
branch is created ?)
Posting here, so you know about this and can push if that's good.

It should work without problems ;-)

HTH,
Matú?


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Disclaimer: http://www.peralex.com/disclaimer.html





___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: help with windows tinbuild and symlinks

[d . ostrovsky]

Zitat von Noel Grandin n...@peralex.com:


Thanks.
With your patch and Michael's hack patch, I can get as far as  
building l10ntools, where it seems to be failing because of the  
recent gbuild-ification.




Could you please provide error log?

Ciao
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: help with windows tinbuild and symlinks

[d . ostrovsky]

Zitat von Noel Grandin n...@peralex.com:




On 2012-05-04 14:11, d.ostrov...@idaia.de wrote:

Could you please provide error log?


Error looks like the isatty() definition is missing somehow? Perhaps  
an include path thing?




Could you please compile idlc module (with make verbose=t to see the  
commands)?

We have there also this lex module idlc/source/scanner.l,
which is also treated as C++.
We changed the treatment from C to C++ for scanners in l10ntools  
module during gbuild'fication.


Thanks
David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] fdo#39643: Remove --disable-strip-solver configure option

[d . ostrovsky]

Zitat von Lubos Lunak l.lu...@suse.cz:


On Tuesday 24 of April 2012, Stephan Bergmann wrote:

On 04/23/2012 06:17 PM, Petr Mladek wrote:
 I am not sure but I think that strip reduces size of binaries even when
 you build without -g. It just removes something less important.

strip removes the table of internal symbols.  The effect is that
backtrace information (whether produced by LO's unmaintained automatic
crash reporting or manually by a capable user) becomes hard to use (or
even next to useless).


 I remember that used to be the case a looong time ago, but is it still valid
today? Assuming this is about means such as the backtrace() call, that is
AFAIK next to useless for normal builds anyway, as it just does not work with
features like hidden visibility. I think debug info is the only usable way to
get backtraces on Linux these days.

 Morever, if I pick e.g. libswlo.so from my devel build and strip  
it, the only

difference is .debug* sections removed, so quite possibly even that table of
internal symbols is a thing of the past.



Do we agree about to drop the striping code from ooinstaller?
As far as I can see the use cases we have are:

Use Case (UC) 1: distro maintainer would build without -g, nothing to
be stripped.

UC 2: developer with change, compile, test cycle would build with -g
and install LO with make install oder make dev-install. He wants
definitely preserve the symbols.

UC 3: developer compiles it with symbols and want provide the build
artifacts to somebody to test.
It could be the only justification to provide a new make target
strip-and-install. But the tests with stripped
artifacts are useless, no deeper analysis is possible. Another
argument for not to strip even in this case is a new configure option
that was introduced in the last hackfest to selectively specify the
list of libraries to build with symbols. With this option not the
whole LO but only a couple of libs would be built with symbols.

If I've not forgotten some use cases, I would suggest to completely
remove the whole stripping stuff from ooinstaller code.

David
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: make check problem in libtest_smoketest building master

[d . ostrovsky]

Zitat von Michael Stahl mst...@redhat.com:


On 12/04/12 12:32, Noel Grandin wrote:



On 2012-04-12 11:51, Stephan Bergmann wrote:

What is the output of

readelf -d
workdir/unxlngx6.pro/LinkTarget/CppunitTest/libtest_smoketest.so

for you?


Output attached.



 0x0001 (NEEDED) Shared library: [libc.so.6]


yeah, that's rather too little :(

this is missing here:


 0x0001 (NEEDED) Shared library: [libsmoketest.so]


indeed looks like your ld defaults to --as-needed.

it should work if you do this:

cd smoketest  make -r clean  make -r LDFLAGS=-Wl,--no-as-needed
subsequentcheck



As it's stated here [1]

*Caution:* Reading the documentation, you may be tempted to try the  
--no-as-needed option as a quick fix workaround, but it's generally  
the not the right fix. If you aren't able to get a package working  
with the --as-needed and --no-copy-dt-needed-entries options enabled,  
it's best to submit a bug report and get expert attention. (It may be  
a sign of deeper flaws in the code or linking strategy of the package.)


[1] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition


wonder what we should do about ld that defaults to --as-needed...

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice



David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice