Re: [Libreoffice] [Libreoffice-qa] LibO 3.5.0 Beta 0 First assessment
Italo Vignoli wrote (06-12-11 01:44) If we stick to Beta 1, though, we should make it VERY clear on the accompanying message that this is a Beta intended to help developers, because advanced users can install it to test features and discover bugs. [...] Yes, the communication has to be clear about this. On the other hand, as written before, of course the beta1 might be good enough for wider testing. Therefore the bug-hunting session initially thought for the Dec. 9/10, will be prepared to be held possibly the week later. If it shows that the beta1 is better for smaller group testing, we will not announce it and push it to a later date. More preparations from me probably today, but more likely tomorrow. I will closely communicate with you Italo, in order to bring the message across clearly. Cheers -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] Naming builds. Please???
On Mon, Dec 05, 2011 at 06:22:33AM -0800, Pedro wrote: >> There might be more commits in the other repositories in the >> meantime => the question is what time to use. We might end up with >> 5 times in the end, e.g.: >> 41491491-41491527-41491568-41491597-41491613 >> It is quite complex in the end. Also, it would be hard for developers to >> get the corresponding commit from it. > That is why I suggested to established a different "birth" date for > each repository. > If we established a 2 day interval since TDF's birthday, then you would have > 414.91491-412.91491-410.91491-408.91491-406.91491 Not, it is still harder than necessary for devs to find what commit this corresponds to. >> I see the following needs and solutions: >> + easily match about dialog with downloaded tarball >> => we need to use the same string in both >> I would add one more line with a time generated by configure >> to the about dialog. The same time should be used in the >> download tarball name > That would be an easier solution. And human readable. So the time you want to put is essentially a "build started" date, and not even that. If an incremental build was done that did not rerun configure, your date is not updated. We can fix that later point by instead making that date a .PHONY target in make, but it still does not satisfy me. I still prefer my "date of last commit to repo" solution. Yes, we have five dates instead of one, but that is the truth... If someone builds with a recent core, but old binfilters, at least it shows. Essentially, the "last commit" date is a *code* *version* *number*, that is completely independent of when the build was done. *That* is what we want. >> + easily match build with git commit >> => keep the git IDs in about dialog > My suggestion was to replace the git IDs altogether with the age > system. No, the git IDs is the only thing that is easy to use in git. Git IDs have to stay. Add the dates as an *alternative* for human consumption, and as a monotonically increasing version number. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Naming builds. Please???
On Mon, Dec 05, 2011 at 06:37:09AM -0800, Pedro wrote: > Lionel Elie Mamane wrote >> You may have missed that my "seconds since the epoch" (in my example: >> 1321480648) is also an age, and has mostly the same properties. It is >> somewhat longer than your format, since it takes an earlier epoch (the >> standard Unix epoch, 1 Jan 1970). >> I don't care strongly which epoch we take; IMHO the Unix epoch is a bit >> easier to handle since standard tools already know this format, but >> that's a pretty minor point. > I didn't miss it. But because I'm not a Dev, I'm not sure I understood. > Do you mean converting the time of extraction from the repositories to a > linear time? No, I meant to use the time of the last change made to the repository. This has the advantage that if two tinderboxes build the same code at different times, the time will be the same. If someone builds (for any reason) old code, the time shown will be old, too. And it does not suffer from race conditions. My proposition means that for a git sha1 commit id, we will always use the same time. For example: Joe finds a but at time 152 Joe hacks, and fixes the bug at time 187 test, etc at time 189, Joe commits fix to his local repository at time 190, Joe tries to push the fix to the central repository at git.freedesktop.org this fails, since there are new changes in the repo that Joe does not have yet Joe downloads the new changes (git fetch) from time 192 to 196 Joe rebases (or merges) his changes with the new changes at time 198 Joe successfully pushes his changes to the central repository at time 201 Someone (tinderbox or Joe or another person) downloads the code - up to the fix by Joe, but with no newer changes - at time 289, builds from time 291 to 295. In this example, I want to use time 198. Similarly, if someone sends a patch to the list, we would use the time that the developer that pushes the change has committed (or rebased/merged) that patch (to his local commit. In this example, your proposition is time 289, right? But then, if another person downloads the very same code at time 315, the time in the about box of his/her build will not be the same, while it is exactly the same code. In my proposition, both builds will have time 198 in the about box. > If it's based on the last time they were updated wouldn't the value > be the same if all the repositories were updated at the same time? Well, AFAIK the repositories are rarely updated (changed) at the same time. The "help" or "artwork" repositories get far fewer commits than the core (code) repository/. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] "make dev-install -o build" does a complete incremental build
On Mon, Dec 05, 2011 at 01:22:16PM +0100, Bjoern Michaelsen wrote: > On Mon, 5 Dec 2011 11:33:45 +0100 > Lionel Elie Mamane wrote: >> After "make" in top directory, one is suggested to do >> make dev-install -o build > That was an unintended sideeffect of the Makefile.in removal. I know > about (thanks moggi), but do not know a simple fix restoring the old > behavior. > All the gory details: > Unfortunately, make does not pass the -o stuff down during recursion Well, in the "usual" way of using recursive make, that would indeed be a bad idea: a target (file) name for "make" is not the same as a target (file) name for "make -C subdir". > (and I found no way to make it do that as the -o stuff is not in > MAKEFLAGS), Even stronger, it is ignored even if you put it in manually :) > Possible workaround: > Creating a quick-dev-install target, that does the same as "dev-install > -o build" and update the docs/hints. That looks good, yes. Or more generally, a variable INSTALL_QUICK, which if set makes *all* install targets not depend on the build: ifndef INSTALL_QUICK DEP_ON_BUILD:=build endif dev-install: $(DEP_ON_BUILD) foo install: $(DEP_ON_BUILD) bar Or maybe rather than "INSTALL_QUICK", make it "INSTALL_NOREBUILD"? It would be used as in: make dev-install INSTALL_QUICK=1 >> Additionally, the incremental build (just after "make" successfully >> finished, no source file touched/changed) relinks quite some libraries >> and JCS/JAR files, I'm not sure why. > For the JCS files it is pretty much unavoidable (...) > As for the relinking, most of it should be solved with: > http://cgit.freedesktop.org/libreoffice/core/commit/?id=2c4537471c932b65e6f72e41881b505c4bbad12c > Are there other gremlins left? I'll test again and let you know.x -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] PostgreSQL-SDBC: Windows & MacOS X porters sought
On Mon, Dec 05, 2011 at 09:01:13PM +0100, Alexander Thurgood wrote: > The build bombs for me with on Mac OSX : > sed -s -e 's/@EXTENSION_VERSION@/0.8.2/' < description.xml > > ../../../unxmacxi.pro/lib/description.xml > sed: illegal option -- s Fixed in commit e53cf6c. Thanks for finding that. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Nuovo messaggio
Agevolazioni per i nuovi Imprenditori. Tassazione al 5% per giovani imprenditori e finanziamento per l'apertura di una nuova azienda Dal 1° gennaio per i giovani che non hanno superato i 35 anni di età e iniziano una nuova attività, è prevista una tassazione agevolata al 5%. Puoi accedere anche a delle agevolazioni finanziarie per iniziare l'attività Per informazioni clicca qui Per non ricevere in futuro news clicca qui ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] LibO 3.5.0 Beta 0 First assessment
On Mon, Dec 5, 2011 at 2:55 AM, Petr Mladek wrote: > Cor Nouws píše v So 03. 12. 2011 v 18:23 +0100: >> Pedro Lino wrote (03-12-11 11:23) >> > I hope that _at least_ they make DAMN sure that Beta1 doesn't >> > overwrite the stable build... >> >> To be honest: I have no idea. I just install zillions (well, little less >> ;-) ) without system integration. >> But your question is relevant indeed. > > We plan to do the beta builds as dev builds, so they will be installed > in parallel with the stable release. > > Though, the release candidates are going to replace the stable releases > on Windows and MAC. euh... on Mac you never actually need to install it. I usually happily run it from the mounted dmg, without bothering drag-and-dropping it in the Application folder. So, regardless of the build mode, on Mac it is quite possible to test without messing the previous 'install' AFAIK Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] LibO 3.5.0 Beta 0 First assessment
On 12/5/11 2:36 PM, Petr Mladek wrote: > I would prefer to keep it as is. In each case, I do not feel like > deciding about this myself. I think that we can stick to Beta 1, although I feel that there would be less misunderstandings by using Alpha (for instance, FileHippo has distributed Beta 0 dropping the 0, and people have started exchanging the link on user groups, so I had to clarify - on the Italian news group - that this is not for the general user). If we stick to Beta 1, though, we should make it VERY clear on the accompanying message that this is a Beta intended to help developers, because advanced users can install it to test features and discover bugs. Otherwise, people - enemies - would start shouting loud that the quality is bad and LO is unusable (although there will always be these idiots, and their existence is a demonstration of the quality of the software, as they shout loud because they are impressed). -- Italo Vignoli - italo.vign...@gmail.com mob +39.348.5653829 - VoIP 5316...@messagenet.it skype italovignoli - gtalk italo.vign...@gmail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] [ANN] LibreOffice 3.5.0 beta0 available
Hi Petr,
Petr Mladek wrote (05-12-11 21:55)
Cor Nouws píše v Po 05. 12. 2011 v 15:52 +0100:
On Ubuntu Linux, I can start/open only one document.
More or less the same as what is written on the wiki ('Writer does not
open a second document')
Prolly as a result of the same bug, it is impossible to export to a PDF.
Will this be fixed in beta1 ... :-)
Both things work for me in the last build => they should be fixed in
beta1.
Good to read :-)
I suggest to switch to the last daily build from
http://dev-builds.libreoffice.org/daily/. See
http://wiki.documentfoundation.org/Development/Tinderbox that says more
details about the tinerboxes producing the builds.
Well, it really becomes interesting of course when all the dust has
settled and beta1 rolls out of the factory ;-)
Unfortunately, beta0 was pretty broken, see my other replay to this
thread. It was bad luck. One bug probably cause many crazy problems.
Sigh, I wrote the reply in the morning and it did not went out. I had to
send it once again few minutes ago :-(
Unfortunate, but not too troublesome, given how circumstances were in
the mean time.
Thanks for your explanation, and I keep fingers crossed for the next step!
Cor
--
- Cor
- http://nl.libreoffice.org
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] License
On Tue, 06 Dec 2011 00:15:10 +0100 Italo Vignoli wrote: > This would be a good story for Mission Impossible 5... You can help me break the build system just before branch off. It is a sure way to make new friends. ;) Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] License
On 12/5/11 11:10 PM, Michael Meeks wrote: > Heh ! :-) I have high hopes for your code hacking ... :-) This would be a good story for Mission Impossible 5... In any case, it looks like there is enough work on the help files for my spare time. In eight years, I have never opened the help files, until last week, when an Italian user pointed me to the file that I have just patched, and to several others Impress help files. It looks like there are more missing information than actual contents... I am digging into the problem, as I think that such a structure for a help file is just nonsense. Users do not find the information they are looking for, and the reason is simple as the structure has been created by someone that was not a (real) user but something else. -- Italo Vignoli - italo.vign...@gmail.com mob +39.348.5653829 - VoIP 5316...@messagenet.it skype italovignoli - gtalk italo.vign...@gmail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Replacing LO SVG handling with OpenOffice code?
Hi Alex, On Mon, 2011-12-05 at 23:49 +0100, Alexander Wilms wrote: > Nice to hear your consent :) Well - it's not my place to do that, Thorsten or the impress guys prolly have a more vigorous view - but I guess they like Armin too so :-) > I figured that it would be too late for 3.5, but I wasn't aware that > both Apache and TDF still need time for the relicensing. > Could you or anyone else give a guesstimate how long that will take? Nope. It is a grindly awful, tedious and painful task. I hope it is only two man weeks of solid pain - but, you know how these things can drag on. > Maybe it'd be useful to have a wiki page for collecting suggestions of > features to be adopted. That might make it easier to keep track of > those features. There is never a shortage of feature suggestions; only of people to do them - so instead we keep a page of features we have actually implemented and we know will be in the next release :-) I find that is more encouraging personally. ATB, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Replacing LO SVG handling with OpenOffice code?
Hi Michael, * Nice to hear your consent :) I figured that it would be too late for 3.5, but I wasn't aware that both Apache and TDF still need time for the relicensing. Could you or anyone else give a guesstimate how long that will take? Maybe it'd be useful to have a wiki page for collecting suggestions of features to be adopted. That might make it easier to keep track of those features. Cheers Alex I just discovered that Apache OpenOffice now uses a new implementation to handle SVGs natively. Since there are a lot of bug reports in LO regarding broken SVGs I'd think using their code would be the best solution. What do you think? Sure - sounds reasonable; Armin's a sharp guy and does some great work; IIRC the core code needed some improvements to make this work really well. A couple of things need sorting out that will make this miss our 3.5 release: first the feature-freeze is ~today. Second - we need to get the licensing situation sorted out; as/when Oracle have finally finished re-licensing under AL2, and we have an MPLv2 out - we'll do the audit / digging work to re-license our code-base MPL/LGPLv3+ (on top of AL2). At that point we'll be able to cherry-pick such things from AOOI easily enough. So - sorry for the delay :-) but it does look like a nice improvement, for sure. All the best, Michael. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix rendering of GTK combobox in RTL
Hi Khaled,
On Fri, 2011-12-02 at 23:43 +0200, Khaled Hosny wrote:
> OK, someone will have to remember fixing them when GTK3 is the default :)
Yes - that will not be for 3.5 though - there are too many issues with
it still I think; it's mostly there for the broadway support (though it
is getting a lot better than it was).
> > inc/vcl/outdev.hxx:sal_BoolIsRTLEnabled() const
> > { return mbEnableRTL; }
> >
> > on the OutputDevice if we have one around to improve efficiency.
>
> That is too complex for me :p so I'll keep doing what seems to work.
Right - we don't have an OutputDevice handy there. Of course - it'd be
dead nice if we had a real signal/slot pattern that could be used to
effectively listen for changes in things like this but ... ;-)
> On a, not so, different note, I found that setting LibreOffice language
> to one different from system language, e.g. LO in Arabic but LANGUAGE is
> set to "en" and vice versa, GTK will be using the directionally of the
> system language, so stuff that get reversed in RTL will not, while it is
> reversed in LibreOffice resulting in the reverse of the bugs being
> fixed.
Haha :-) so that is perhaps hard to avoid for the pure gtk+ dialogs
such as the file-picker; and hopefully mostly a problem for testing,
however for our captive widgets we could re-train them with:
gtk_widget_set_direction
as/when it changes; and we could use:
gtk_widget_set_default_direction
as well I guess for the native dialogs. Arguably we should have a hook
that does that when we change our direction at run-time. Having said
that - the call looks pretty cheap (if there is no change), so we could
call it a lot ;-)
> This is really a huge improvements in the RTL UI, and case I didn't say
> it before, LibreOffice is really the best thing that happened to OOo
> since it was leashed upon the world (and I like the name, BTW).
Cool :-) well, LibreOffice is only awesome & fun because of good guys
like you jumping in and improving it left & right.
Thanks :-)
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Replacing LO SVG handling with OpenOffice code?
Hi Alex, On Mon, 2011-12-05 at 17:35 +0100, Alexander Wilms wrote: > Just to quickly introduce myself: I'm Alex and I mostly take part in > discussions on the design mailing list. Great. > I just discovered that Apache OpenOffice now uses a new implementation > to handle SVGs natively. Since there are a lot of bug reports in LO > regarding broken SVGs I'd think using their code would be the best > solution. What do you think? Sure - sounds reasonable; Armin's a sharp guy and does some great work; IIRC the core code needed some improvements to make this work really well. A couple of things need sorting out that will make this miss our 3.5 release: first the feature-freeze is ~today. Second - we need to get the licensing situation sorted out; as/when Oracle have finally finished re-licensing under AL2, and we have an MPLv2 out - we'll do the audit / digging work to re-license our code-base MPL/LGPLv3+ (on top of AL2). At that point we'll be able to cherry-pick such things from AOOI easily enough. So - sorry for the delay :-) but it does look like a nice improvement, for sure. All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] bidi/rtl languages (cosmetic change only)
On Sun, 2011-12-04 at 23:37 +0200, Lior Kaplan wrote: > Following Andrads's commit to the bidilanguages variable found pushed :-) Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] License
On Mon, 2011-12-05 at 18:50 +0100, Italo Vignoli wrote: > All my patches are LGPLv3/MPL. Lovely :-) > For those worried by such a statement, I hereby promise that I will > focus on help files and will carefully avoid the real code. Heh ! :-) I have high hopes for your code hacking ... :-) Thanks, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH 01/11] Replace ScChangeTrackMsgStack with std::stack< ScChangeTrackMsgInfo* >
Hi, On Monday, 2011-12-05 23:05:33 +0100, Eike Rathke wrote: > Good stuff, pushed to master with only a few corrections: And now also marked as [PUSHED] in the subject ... Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpsHfHeXAzkk.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH 01/11] Replace ScChangeTrackMsgStack with std::stack< ScChangeTrackMsgInfo* >
Hi Marcel, On Thursday, 2011-12-01 11:08:40 +0100, Marcel Metz wrote: > this is my first patch series to the lo project. It replaces the use > of the tools Stack class and corresponding macros with the std::stack > as suggested in in bug #39445 [1] (an easy hack). Yay! class Stack is gone from core :-) Good stuff, pushed to master with only a few corrections: http://cgit.freedesktop.org/libreoffice/core/commit/?id=0158333f1b8d578cc56dc51c3e3f8daf0578210b http://cgit.freedesktop.org/libreoffice/core/commit/?id=149c1746a1e2ee0557c72c067fe6fe79f0781c4d http://cgit.freedesktop.org/libreoffice/core/commit/?id=ecfcc545433d30e3b70fd0c909cce782edbdee39 http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c6bc18961eb74074183a68d8dbea7e4bbefe059 http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5b63844cc6a4b96fcf0db0c0c9c1194847fc914 http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc6431f7fde63691a0022bec662e554b0bd432ed http://cgit.freedesktop.org/libreoffice/core/commit/?id=49ac37ddfcd39eef947d4d4d5805e89bfa4ca063 http://cgit.freedesktop.org/libreoffice/core/commit/?id=b3ba4376c6f5e63aeeadec95c51bcd164d10f2b5 http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c173e748936231846c9e3e87832754c496ebc35 http://cgit.freedesktop.org/libreoffice/core/commit/?id=050b170e8cf911679a4d3697ae81ee49e67d10a7 http://cgit.freedesktop.org/libreoffice/core/commit/?id=072b13738781f78a8318053d8cfea39558de17f5 Plus the adaption in binfilter http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=f10b863248237e9878bb7e3603016d21f1868b93 Thanks again Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpTglv65tywm.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error with xulrunner 8.0
2011/12/5 Andreas Radke : > > any idea? > > I've found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470442 that may > be the same or > similar. > > -Andy Even tho the build is failing which is interesting I would have suggestion for your distro package. As the mozab integration and whole internal mozilla is built just for sake of not-working-on-linux adresbook stuff and not-really-working-ldap i would say you could try to do same as we do in Gentoo and pass: --disable-mozilla \ --without-system-mozilla \ For more stuff see the ebuild and the configure switches comments: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-office/libreoffice/libreoffice-3.5.0.0.ebuild?revision=1.4&view=markup Note that ldap with openldap really does not work. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error with xulrunner 8.0
Am Fri, 2 Dec 2011 10:09:13 +0100 schrieb Tomáš Chvátal : > Sweet looks like mozilla wants to make everyone happy and changed the > format again... > Could you try to build it with npapi-sdk rather than with xulrunner? Trying now without system xulrunner, using internal seamonkey source and these switches: --without-system-mozilla-headers gives checking whether to enable build of Mozilla... yes checking whether to build Mozilla addressbook connectivity... yes checking whether to build XML Security support... yes checking whether to build LDAP configuration backend... OpenLDAP checking ldap.h usability... yes checking ldap.h presence... yes checking for ldap.h... yes checking for ldap_simple_bind_s in -lldap... yes checking for ldap_set_option in -lldap... yes checking which Mozilla to use... internal checking for toolkit Mozilla should use... gtk2 checking whether to build Mozilla/SeaMonkey... yes checking for Mozilla sources... checking for a169ab152209200a7bad29a275cb0333-seamonkey-1.1.14.source.tar.gz... found checking for MOZLIBREQ... yes checking for MOZLIBREQ... yes checking which NSS to use... external checking for NSS... yes checking which mozilla headers to use... internal build breaks this way [ build CXX ] vcl/source/control/spinbtn Compiling: sdext/source/presenter/PresenterTimer.cxx /usr/lib/libcrmf.a(crmfenc.o): In function `CRMF_EncodeCertReqMsg': crmfenc.c:(.text+0x1f): undefined reference to `SEC_ASN1Encode_Util' /usr/lib/libcrmf.a(crmfenc.o): In function `CRMF_EncodeCertRequest': crmfenc.c:(.text+0x4f): undefined reference to `SEC_ASN1Encode_Util' /usr/lib/libcrmf.a(crmfenc.o): In function `CRMF_EncodeCertReqMessages': crmfenc.c:(.text+0x89): undefined reference to `SEC_ASN1Encode_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x70): undefined reference to `SECOID_AlgorithmIDTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x90): undefined reference to `SECOID_AlgorithmIDTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0xb0): undefined reference to `SEC_BitStringTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0xd0): undefined reference to `SECOID_AlgorithmIDTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0xf0): undefined reference to `SEC_OctetStringTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x150): undefined reference to `SEC_AnyTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x190): undefined reference to `SEC_AnyTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x1d0): undefined reference to `SEC_BitStringTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x210): undefined reference to `SEC_IntegerTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x250): undefined reference to `SEC_BitStringTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x290): undefined reference to `SEC_NullTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x450): undefined reference to `SEC_AnyTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x470): undefined reference to `SECOID_AlgorithmIDTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x490): undefined reference to `SEC_BitStringTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x4f0): undefined reference to `SEC_IntegerTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x510): undefined reference to `SEC_IntegerTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x530): undefined reference to `SECOID_AlgorithmIDTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x5d0): undefined reference to `SEC_BitStringTemplate_Util' /usr/lib/libcrmf.a(crmftmpl.o):(.data.rel.ro+0x5f0): undefined reference to `SEC_BitStringTemplate_Util' /usr/lib/libcrmf.a(crmfreq.o): In function `crmf_copy_bitstring': crmfreq.c:(.text+0x33): undefined reference to `SECITEM_CopyItem_Util' /usr/lib/libcrmf.a(crmfreq.o): In function `crmf_encode_integer': crmfreq.c:(.text+0x55): undefined reference to `SEC_ASN1EncodeInteger_Util' /usr/lib/libcrmf.a(crmfreq.o): In function `crmf_encode_unsigned_integer': crmfreq.c:(.text+0x75): undefined reference to `SEC_ASN1EncodeUnsignedInteger_Util' /usr/lib/libcrmf.a(crmfreq.o): In function `CRMF_CreateCertRequest': crmfreq.c:(.text+0x18e): undefined reference to `PORT_NewArena_Util' crmfreq.c:(.text+0x1a3): undefined reference to `PORT_ArenaZAlloc_Util' crmfreq.c:(.text+0x1d7): undefined reference to `PORT_FreeArena_Util' /usr/lib/libcrmf.a(crmfreq.o): In function `CRMF_DestroyCertRequest': crmfreq.c:(.text+0x216): undefined reference to `PORT_Free_Util' crmfreq.c:(.text+0x227): undefined reference to `PORT_Free_Util' crmfreq.c:(.text+0x23d): undefined reference to `PORT_FreeArena_Util' /usr/lib/libcrmf.a(crmfreq.o): In function `crmf_template_copy_secalg': crmfreq.c:(.text+0x27b): undefined reference to `PORT_ArenaMark_Util' crmfreq.c:(.text+0x28b): undefined reference to `PORT_ArenaZAlloc_Util' any idea? I've found http://bugs.debian.org/
Re: [Libreoffice] [Libreoffice-qa] [ANN] LibreOffice 3.5.0 beta0 available
Cor Nouws píše v Po 05. 12. 2011 v 15:52 +0100:
> Rainer Bielefeld wrote (05-12-11 14:26)
> >> https://wiki.documentfoundation.org/Releases/3.5.0/Beta0
> >
> > I added a comment concerning install / uninstall problems on SIN 64 bit
> > systems.
>
>
> On Ubuntu Linux, I can start/open only one document.
> More or less the same as what is written on the wiki ('Writer does not
> open a second document')
>
> Prolly as a result of the same bug, it is impossible to export to a PDF.
>
> Will this be fixed in beta1 ... :-)
Both things work for me in the last build => they should be fixed in
beta1.
I suggest to switch to the last daily build from
http://dev-builds.libreoffice.org/daily/. See
http://wiki.documentfoundation.org/Development/Tinderbox that says more
details about the tinerboxes producing the builds.
Unfortunately, beta0 was pretty broken, see my other replay to this
thread. It was bad luck. One bug probably cause many crazy problems.
Sigh, I wrote the reply in the morning and it did not went out. I had to
send it once again few minutes ago :-(
Best Regards,
Petr
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Renamed Linux dev packages
Hi, we decided to use dev build for the official 3.5 beta builds but there was missing desktop integration on Linux. It was not easy to add it if the package name include dash '-'. In addition, there were inconsistencies because most package names were "libo-dev" but the ure package was "lodev". Finally, it was installed into "/opt/lo-dev'. I solved it by renaming everything to "lodev". I hope that it will not break anything. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibO 3.5.0 Beta 0 First assessment
Rainer Bielefeld píše v So 03. 12. 2011 v 08:42 +0100: > Hello, > > it's a disaster, completely unusable! Quality of Beta0 is far behind > quality of Master during the last weeks, it seems that we were not lucky > with the time where the tag has been created ad got a very broken source. I think that it was bad luck. When I look at the bug: https://bugs.freedesktop.org/show_bug.cgi?id=43383, beta0 was not able to open more documents. I think that the whole application was in a strange state after opening the fist document. I think that was basically unusable. IMHO, the bug had many various scenarios. Unfortunately, this was was not visible during the smoke test. I did not have time for wider testing. I had big troubles to find something buildable. On the other hand, beta0 helped to find the problem with parallel installation. It was exactly the thing why we did it. I currently see only only one blocker bug in the 3.5 most annoying bugs: + https://bugs.freedesktop.org/show_bug.cgi?id=43422 Spell check: Crash "Runtime Error" with AutoSpellcheck It seems that it crashes only when you select a function in context menu. We have to fix it but it does not block wider testing of LO. So, it does not block beta1 and the current state looks promissing to me. Note that we want to do more checks before creating the tag for beta1. Beta0 was primary for build and installation tests. Beta1 should be usable for functional tests. Anyway, if you know about anything that is serious, please add it to the most annoying bugs. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Replacing LO SVG handling with OpenOffice code?
Hi guys, Just to quickly introduce myself: I'm Alex and I mostly take part in discussions on the design mailing list. I just discovered that Apache OpenOffice now uses a new implementation to handle SVGs natively. Since there are a lot of bug reports in LO regarding broken SVGs I'd think using their code would be the best solution. What do you think? Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33554 (There are some more, though) Post on Apache OpenOffice: http://eric.bachard.org/news/index.php?post/2011/12/03/In-progress-%3A-native-support-of-the-SVG-graphic-format-in-Apache-OpenOffice.org Kind Regards Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build Libo - Error when execute ./autogen.sh
Hello Le Mon, 05 Dec 2011 12:07:45 +0100, Alex Sandro Fagundes a écrit: Hi, I'm tried build libo, but I'm with problems how showed on annex. I tried several forms, but not work. I tried: --with-jdk-home=/cygdrive/c/Program Files/Java/jdk1.6.0_25 --with-jdk-home="C:\DXSDK" --with-jdk-home="C:\Program Files\Microsoft SDKs\Windows\v6.0A" Your settings should be --with-jdk-home=/cygdrive/c/Program Files/Java/jdk1.6.0_25 --with-directx-home="C:\DXSDK" --with-windows-sdk-home="C:\Program Files\Microsoft SDKs\Windows\v6.0A" Could you confirm this is a typo in your email ? Regards Mathias ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] PostgreSQL-SDBC: Windows & MacOS X porters sought
Le 05/12/11 00:22, Lionel Elie Mamane a écrit : Hi Lionel, The build bombs for me with on Mac OSX using : --with-system-postgresql in connectivity/drivers/source/postgresql with the following error : sed -s -e 's/@EXTENSION_VERSION@/0.8.2/' < description.xml > ../../../unxmacxi.pro/lib/description.xml sed: illegal option -- s usage: sed script [-Ealn] [-i extension] [file ...] sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...] dmake: Error code 1, while making '../../../unxmacxi.pro/lib/description.xml' dmake: '../../../unxmacxi.pro/lib/description.xml' removed. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH 01/11] Replace ScChangeTrackMsgStack with std::stack< ScChangeTrackMsgInfo* >
Hi Michael, On Monday, 2011-12-05 19:07:35 +0100, Michael Stahl wrote: > > Would be great if you could complete the work on binfilter. > > clarifying remark: > please don't refactor binfilter, it is not worth the effort! > > don't replace Stack with std::stack in binfilter, but instead just move > the header from tools somewhere into binfilter, adapt the #includes, and > be done with it. Indeed might be the best solution in this case, as there is no implementation to be moved along with. Ok, Marcel, freeze! ;-) I'll do the remaining work. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpArdZWPP9xY.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Expending LO Math capabilities
Hello all,
I've asked the same question in the users mailing list but didn't
receive an answer, maybe you could help more.
I'm looking for a way to customize Math. I would like to make
predefined symbols (somthing like %dVol => dxdydz or %eye{3} => 3x3
identity matrix).
are there any accessible files to edit to achieve this? Or some other way maybe?
If not, adding the option to create this kind of macros would by great.
Thanks
--
View this message in context:
http://nabble.documentfoundation.org/Expending-LO-Math-capabilities-tp3562178p3562178.html
Sent from the Dev mailing list archive at Nabble.com.___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH 01/11] Replace ScChangeTrackMsgStack with std::stack< ScChangeTrackMsgInfo* >
On 05/12/11 18:26, Eike Rathke wrote: > Hi Marcel, > > On Thursday, 2011-12-01 11:08:40 +0100, Marcel Metz wrote: > >> this is my first patch series to the lo project. It replaces the use >> of the tools Stack class and corresponding macros with the std::stack >> as suggested in in bug #39445 [1] (an easy hack). > > As already mentioned on IRC on Friday, one thing that's missing is all > replacements in the code of the binfilter repository, when reworking the > entire code base that needs to be included in the build to catch things, > here specifically the class Stack that will be gone now. The binfilter > is in large pieces a snapshot of the code, but some low level modules > are shared and not duplicated, as unfortunately here is the case with > module tools. Note that to catch all places before building you best > remove solver/$INPATH/inc/tools/stack.hxx and then > rm binfilter/$INPATH/misc/*.dp* > to remove the old dependency files the compiler would complain about > because of the removed stack.hxx not found. > > Would be great if you could complete the work on binfilter. clarifying remark: please don't refactor binfilter, it is not worth the effort! don't replace Stack with std::stack in binfilter, but instead just move the header from tools somewhere into binfilter, adapt the #includes, and be done with it. one day we will throw out the binfilter altogether, and there will be much rejoicing... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] License
All my patches are LGPLv3/MPL. For those worried by such a statement, I hereby promise that I will focus on help files and will carefully avoid the real code. Best, Italo Italo Vignoli Mobile +39.348.5653829 Email italo.vign...@gmail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH 01/11] Replace ScChangeTrackMsgStack with std::stack< ScChangeTrackMsgInfo* >
Hi Marcel, On Thursday, 2011-12-01 11:08:40 +0100, Marcel Metz wrote: > this is my first patch series to the lo project. It replaces the use > of the tools Stack class and corresponding macros with the std::stack > as suggested in in bug #39445 [1] (an easy hack). As already mentioned on IRC on Friday, one thing that's missing is all replacements in the code of the binfilter repository, when reworking the entire code base that needs to be included in the build to catch things, here specifically the class Stack that will be gone now. The binfilter is in large pieces a snapshot of the code, but some low level modules are shared and not duplicated, as unfortunately here is the case with module tools. Note that to catch all places before building you best remove solver/$INPATH/inc/tools/stack.hxx and then rm binfilter/$INPATH/misc/*.dp* to remove the old dependency files the compiler would complain about because of the removed stack.hxx not found. Would be great if you could complete the work on binfilter. However, I promised you some remarks about some caressing I did with your patch, they'll arrive shortly as a separate mail :-) > I would like to continue with cleaning up the tools module. I've seen > that there are other containers in tools like a Table which probably > could be replaced in most places with a std::table or a std::vector Yes, but there is no ::std::table, ::std::map would be appropriate to lookup a key and obtain a corresponding value. > and the List that could be replaced with std::vector. Yes. Some work has already been done on that, there might be something left. > Should I set up a new Bug for that or can I just hack on if there > aren't any objections on these changes? Hack on :-) Especially for these tools' container types there's already https://bugs.freedesktop.org/show_bug.cgi?id=38832 > [1] https://bugs.freedesktop.org/show_bug.cgi?id=39445#c1 Thanks for the pointer, originally that bug was about something different, I added a pointer there to the other bug. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpMLwNDh4ZR0.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] bidi/rtl languages (cosmetic change only)
On Mon, Dec 5, 2011 at 7:09 PM, Andras Timar wrote: > Hi Kaplan, > > 2011/12/4 Lior Kaplan : > > Hi, > > > > Following Andrads's commit to the bidilanguages variable > > ( > http://cgit.freedesktop.org/libreoffice/core/commit/?id=93cf9e1f2b4a269dfe4fd90945dd2f7c50277db5 > ), > > I've made a small cosmetic patch as these languages are RTL (which for > them > > we need bidi support). > > > > Comments? > > > > git grep -i bidi gives a lot more hits. Why would you like to change > two variable names, while there are a lot more occurences in function > names, etc. It would be more confusing than it is now. > As I said this is a cosmetic change, which is aiming for correctness of the term itself. Yes, bidi appears in a lot of places, most of them are the right use of the term. This change is small and easy to do, otherwise it wouldn't worth the time investment for something cosmetic. Kaplan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] bidi/rtl languages (cosmetic change only)
Hi Kaplan, 2011/12/4 Lior Kaplan : > Hi, > > Following Andrads's commit to the bidilanguages variable > (http://cgit.freedesktop.org/libreoffice/core/commit/?id=93cf9e1f2b4a269dfe4fd90945dd2f7c50277db5), > I've made a small cosmetic patch as these languages are RTL (which for them > we need bidi support). > > Comments? > git grep -i bidi gives a lot more hits. Why would you like to change two variable names, while there are a lot more occurences in function names, etc. It would be more confusing than it is now. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#42286, do not shrink the selected area (2)
Hi Pierre-André, On Sunday, 2011-12-04 22:25:51 +0100, Pierre-André Jacquod wrote: > The first one is my favorite: > 0001-fdo42286-strict-use-of-GetDataArea-and-strict-extens.patch > it extends the area down. It takes into account the cells strictly > below the already selected area. It never shrinks / shortens the > selected area. This is the one that implement in my opinion the best > the behaviour of adding data below already active area. > > The second one: > 0001-fdo42286-extend-down-but-also-shrink-if-cells-are-em.patch > has the same logic, except it allows to shrink the area, if cells > are emptied. This the filter is allowed to extend, it could be seen > as logic that it is also allowed to shrink. For consistency it makes sense to also shrink the area, as re-initializing the filter area with only one cell or one row selected would produce the same result (plus additional columns). Also, if the area was never shrunk and later data added in that area but not part of the actual data area (not contiguous area) that data would be erroneously included. Please go ahead with this one. Please check that a defined data base range did not change behavior with your previous changes. Regarding variable names, it may be better to stick with naming conventions of already existing code, i.e. it should be bShrink and bNeedExtend, makes the code easier to read. Thanks. > The last one: > 0001-fdo42286-extend-down-even-if-last-row-empty-but-a-co.patch > extend down, but also if data is added to the first cell bellow. so > if you have something like (o means empty cell, x cell with data), > initial filter only on B2:D3 > o > oXXXo > oXXXo > X > and add the last X below right, the the last line will be included > in the area and shown with "empty cells" selection. I do not like > this, since it suddenly take into account a column which was not > part of the initial filtered area. Mainly because it doesn't fulfill the contiguous data area aspects, for which at least E3 or D4 would also have to contain data. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpfl0x8bZg1f.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] "make dev-install -o build" does a complete incremental build
On Mon, Dec 5, 2011 at 7:04 AM, Stephan Bergmann wrote: > On 12/05/2011 01:22 PM, Bjoern Michaelsen wrote: > > > Wouldn't it be better to remove the "recurse to get the Env etc." magic? My > understanding is that ultimately we want to get rid of having to source > Env.Host.sh by replacing it with a file included by gbuild.mk, not by > sourcing it behind the scenes, right? Once we are there, toplevel make > command line arguments should behave as expected. I see no need to break > that in the meantime. Note originally I only had that 'magic' for module rebuild... so the -o filtering was not a problem. And yes I agree that the include instead of source will simplify things a lot and make that issue moot. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Running in terminal: different output (incl. backtrace /memory map) than after previous builds - something changed?
Hi, Did a pull -r amd make clean and a make dev-install last Thuesday Then ran solenv/bin/ooinstall Now when running in a terminal, I get regular output. And on errors a backtrace /memory map. Which I did not get before, when I did a build in the same way.. Has anything changed on purpose or by accident? Cheers, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] [ANN] LibreOffice 3.5.0 beta0 available
Rainer Bielefeld wrote (05-12-11 14:26)
https://wiki.documentfoundation.org/Releases/3.5.0/Beta0
I added a comment concerning install / uninstall problems on SIN 64 bit
systems.
On Ubuntu Linux, I can start/open only one document.
More or less the same as what is written on the wiki ('Writer does not
open a second document')
Prolly as a result of the same bug, it is impossible to export to a PDF.
Will this be fixed in beta1 ... :-)
--
- Cor
- http://nl.libreoffice.org
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] PostgreSQL-SDBC: enable by default on GNU/Linux, BSD
Lionel Elie Mamane píše v Po 05. 12. 2011 v 11:25 +0100: > Hi, > > So, PostgreSQL-SDBC is now in libreoffice master branch, but not > enabled by default. Let's enable it by default on "traditional" Unices > (GNU/Linux, BSD, but not MacOS X yet), where we have a working > internal libpq (PostgreSQL C client library), so no extra build > dependency. > > I would be nice if tinderboxes for these platforms (i.e. only > GNU/Linux AFAIK) would build it too, to get a bit more test coverage > than my Debian box :) Do the tinderboxes just use distro-config/FOO or > does this need manual intervention by the tinderbox operators? AFAIK, the Linux-*-Release_Configuration tinderboxes use the distro-config/FOO. I am afraid that the others does not use it. They mostly use the default configuration defined by configure.in. I have added the maintainers into CC. See also http://wiki.documentfoundation.org/Development/Tinderbox > If enabling it breaks the tinderbox build (on a traditional Unix), warn > me, I'll take care of it. Thanks for helping with it. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Naming builds. Please???
Hi Lionel Lionel Elie Mamane wrote > > You may have missed that my "seconds since the epoch" (in my example: > 1321480648) is also an age, and has mostly the same properties. It is > somewhat longer than your format, since it takes an earlier epoch (the > standard Unix epoch, 1 Jan 1970). > > I don't care strongly which epoch we take; IMHO the Unix epoch is a bit > easier to handle since standard tools already know this format, but > that's a pretty minor point. > I didn't miss it. But because I'm not a Dev, I'm not sure I understood. Do you mean converting the time of extraction from the repositories to a linear time? Wouldn't the values for all repositories be the same if you extract them all at the same time? If it's based on the last time they were updated wouldn't the value be the same if all the repositories were updated at the same time? This is why I'm suggesting an arbitrary birth date with (at least) a 2 day difference (see other email to Petr) Best regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Naming-builds-Please-tp3556898p3561591.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] Naming builds. Please???
Hi Petr > Hmm, we check out the five repositories one by one. It might take some > time if you have slower network connection. There might be more commits > in the other repositories in the meantime => the question is what time > to use. We might end up with 5 times in the end, e.g.: > > 41491491-41491527-41491568-41491597-41491613 > > It is quite complex in the end. Also, it would be hard for developers to > get the corresponding commit from it. That is why I suggested to established a different "birth" date for each repository. If we established a 2 day interval since TDF's birthday, then you would have 414.91491-412.91491-410.91491-408.91491-406.91491 Because the part before the point means days, a build from the following day would be (assuming there were changes only to the core) 415.67866-412.91491-410.91491-408.91491-406.91491 I.e. you only need to read the first 3 digits to realize if it's older or newer. Even better: because the fraction part after the point is also time, you know that any value below 0.5 is before noon and any value greater is between noon and midnight. > I see the following needs and solutions: > > > + easily match about dialog with downloaded tarball > > => we need to use the same string in both > > I would add one more line with a time generated by configure > to the about dialog. The same time should be used in the > download tarball name That would be an easier solution. And human readable. > + easily match build with git commit > > => keep the git IDs in about dialog My suggestion was to replace the git IDs altogether with the age system. This solves the potential problem of the truncated 7 digits of the SHA repeating sometime in the future and it is human readable. But this is secondary if the date-time code is added to the about box and to the tarball name (or Windows installer ;) ) > + human readable string for official builds for normal users: > > => I would add one more line, .e.g. 3.5.0-beta1 > it will be used only in the official builds generated from > release tarballs or release tags Couldn't agree more! > > Does it make sense? Yes. I think that covers all problems. Best regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Naming-builds-Please-tp3556898p3561557.html Sent from the Dev mailing list archive at Nabble.com.___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] LibO 3.5.0 Beta 0 First assessment
Cor Nouws píše v So 03. 12. 2011 v 18:27 +0100: > Michael Meeks wrote (03-12-11 15:50) > > > Yes ! we have not branched yet; master will branch at the > > feature-freeze before B1 so we have: > > > > master Beta0 ---\--- crazy stuff ... > >\ > > \- Beta1 --- stabilisation - Beta2 > > > > etc. :- > > Correct. While explaining the whole event to someone else, suddenly it > became clear to me it might be much clearer when we have another naming > scheme: > > master - Alpha1 ---\--- crazy stuff ... > \ > \- Alpha2 --- stabilisation - Beta1 > > The great advantage of this is, that people having some expectation on > what a beta1 is, will not be disappointed. > Also, the whole schedule will not change, only the naming will be > conform what people get offered. > Will be something that marketing is going to praise us for, isn't it? Hmm, I am not sure. IMHO, the naming scheme is a big social engineering game. openSUSE started using milestones instead of alpha/beta versions two years ago. One reason was that alpha made people feel that it was something non-stable => developers did not care, testers did not test. Also it solved the problem with the very broken beta1. This time, for 12.1 release, they introduced beta and rc back again. I think that it was because the milestones were confusing. Milestone8 did not indicate that it was after feature freeze and that it was last release before rc. People were surprised that there was milestone8 and then rc1. Nobody was ready for such quick release and no time for bugfixing. I am afraid that if we call beta1 as alpha1, people will not test it much. I would prefer to keep it as is. In each case, I do not feel like deciding about this myself. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] [ANN] LibreOffice 3.5.0 beta0 available
Thorsten Behrens schrieb: https://wiki.documentfoundation.org/Releases/3.5.0/Beta0 Hello, I added a comment concerning install / uninstall problems on SIN 64 bit systems. Best regards Rainer ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] LibO 3.5.0 Beta 0 First assessment
Pedro Lino píše v Po 05. 12. 2011 v 09:48 +: > > We plan to do the beta builds as dev builds, so they will be installed > > in parallel with the stable release. > > Excellent news! > Is this going to be included on the first Public Beta which is > scheduled for today? Yes, beta1 will be dev-build and will install in parallel with 3.4. > > Though, the release candidates are going to replace the stable releases > > on Windows and MAC. They still will install in parallel with 3.4 on > > Linux. So, it will work the same way like with 3.4 vs. 3.3. > > Can't this be consistent across OSes? > What option allows RCs to be installed in parallel in Linux? > Can't we use the same option in Windows and Mac? There is no special option. It is a side effect of the packaging approach. The package names include the version 3.4, 3.5. The rpm/deb package managers think that they are different packages. The windows installer ignores the name and uses a special ID that is bundled inside the installer. We do not change the ID for different Windows versions. I agree that the should be consistent. Well, I am not sure what solution is correct. Most normal users do not want to have several LO versions installed in parallel. So, maybe, we should rather "fix" the Linux solution. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build Libo - Error when execute ./autogen.sh
I have the SDK installed correctly. But still not work. 2011/12/5 Lionel Elie Mamane : > On Mon, Dec 05, 2011 at 09:07:45AM -0200, Alex Sandro Fagundes wrote: > >> I'm tried build libo, but I'm with problems how showed on annex. >> I tried several forms, but not work. > > Have you installed the Windows Installer SDK? I think it is part of > the Windows (Platform) SDK, but maybe it is not installed by default > or you removed it from the list of components to be installed. Run the > Windows SDK installer again and make sure you select the Windows > Installer SDK component for installation. > > Have you already found the page > http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies > ? > > Just a small note: please try to send the error messages as text > rather than graphic, it makes it much more convenient to > read. Right-click on the console (or system menu / edit), choose > "mark" (or similar: maybe select, not sure anymore), select what you > want and press enter. Then go to your email and paste the error > message in. > > -- > Lionel -- Att, Alex Sandro Fagundes Twitter: @alexsfagundes Email : alexsfagun...@gmail.com Fone: (47) 84459054 WEB SITE: www.descobrindoideias.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] "make dev-install -o build" does a complete incremental build
On 12/05/2011 01:22 PM, Bjoern Michaelsen wrote: We now have a gbuild makefile on the toplevel and I recurses to get the Env etc. since shm_get implemented that to get rid of the need to source the Env in the shell. Unfortunately, make does not pass the -o stuff down during recursion (and I found no way to make it do that as the -o stuff is not in MAKEFLAGS), so that change broke the use of -o and possibly quite a few more advanced flags to GNU make. No one noticed as people rarely seem to use it unless directly suggested to do so. Wouldn't it be better to remove the "recurse to get the Env etc." magic? My understanding is that ultimately we want to get rid of having to source Env.Host.sh by replacing it with a file included by gbuild.mk, not by sourcing it behind the scenes, right? Once we are there, toplevel make command line arguments should behave as expected. I see no need to break that in the meantime. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] "make dev-install -o build" does a complete incremental build
Hi Lionel, On Mon, 5 Dec 2011 11:33:45 +0100 Lionel Elie Mamane wrote: > After "make" in top directory, one is suggested to do > > make dev-install -o build > > This used to skip the build and just do the dev-install part, but not > anymore. That's rather annoying, as an incremental build that does > nothing takes quite some time to notice it has to do nothing (and run > unittests). That was an unintended sideeffect of the Makefile.in removal. I know about (thanks moggi), but do not know a simple fix restoring the old behavior. All the gory details: We now have a gbuild makefile on the toplevel and I recurses to get the Env etc. since shm_get implemented that to get rid of the need to source the Env in the shell. Unfortunately, make does not pass the -o stuff down during recursion (and I found no way to make it do that as the -o stuff is not in MAKEFLAGS), so that change broke the use of -o and possibly quite a few more advanced flags to GNU make. No one noticed as people rarely seem to use it unless directly suggested to do so. Possible workaround: Creating a quick-dev-install target, that does the same as "dev-install -o build" and update the docs/hints. > Additionally, the incremental build (just after "make" successfully > finished, no source file touched/changed) relinks quite some libraries > and JCS/JAR files, I'm not sure why. That too is annoying in itself, > and makes the above only worse. For the JCS files it is pretty much unavoidable as the java compiler has no clear 1:1 file relation between source and class files, so they have to be rerun. However, IIRC the java compiler does not recompile stuff it recognized to be up-to-date, but still that is a lot slower then make itself would be. One could consider to externally generate deps for JCS, but that is likely fragile too. Better minimize the use of Java instead ;) As for the relinking, most of it should be solved with: http://cgit.freedesktop.org/libreoffice/core/commit/?id=2c4537471c932b65e6f72e41881b505c4bbad12c Are there other gremlins left? Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Patch] Code review fix
Ah...that didn't strike me...because I assumed it is again converted back to 8bit by shifting back...which is the case as well in some functions e.g. GetColor()...but then it doesn't seem to matter so much as much as for up-sampling. Thank you for the clarifications. Yes, 65535/255 or 0x/0xFF might help. Thanks again, Muthu Subramanian On 12/05/2011 05:12 PM, Tor Lillqvist wrote: > The idea is that the 8-bit input range 0..255 should map to the 16-bit > output range 0..65535 ... Try the original code, compared to your > suggestion;) > > (To be honest, multiplying by 257 did sound weird to me, too, but then > I realized that 257 == 65535/255 . I would perhaps write out the > 65535/255 explicitly and let the compiler fold it to 257.) > > --tml > ___ > 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
Re: [Libreoffice] XDG config migration
On 12/05/2011 10:40 AM, Tomáš Chvátal wrote: After updating to 3.5 quite few people reported that their configuration is gone and they have default setup. The reason for this is that 3.5 now uses XDG spec ~/.config/libreoffice instead of ~/.libreoffice. Simple copy of later folder to replace the former one solved the issued for everyone. In my humble opinion I think that this migration should be done automatically and user should not be bothered by this (even packagers should not do this as we should mostly NOT touch user homedirs). Wouldn't it be better to postpone the change to LO 4? Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Patch] Code review fix
The idea is that the 8-bit input range 0..255 should map to the 16-bit output range 0..65535 ... Try the original code, compared to your suggestion;) (To be honest, multiplying by 257 did sound weird to me, too, but then I realized that 257 == 65535/255 . I would perhaps write out the 65535/255 explicitly and let the compiler fold it to 257.) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Windows (MSVC) incremental build is broken.
Hi Kendy, all, On Mon, Dec 05, 2011 at 02:03:11AM +0100, Jan Holesovsky wrote: > In the end, I worked that around using this: > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=f259162cf511528c210eb71f51e63b5ff6838ff5 > > I still believe the rewriting of the OUTDIR & friends in BuildDirs.mk is > wrong, and should be avoided, but after trying to unwind that for an > hour, I just gave up, and went the easy way... > > Bjoern - if you can sanitize this at some stage, that would be most > appreciated. > > Tinderbox restarted, hopefully it will be green in the morning again. Well, there is a good reason for paths in GNU make to be unix-paths. You define a rule as: C:B true for target C depending on B. If you use windows native paths something like: C:B:D true is valid and can mean either target C depending on target B:D or target C:B depending on target D. IIRC there are some heuristics in the DOS/Windows native version GNU make, but I am not even sure if cypath has those too (and as this is a cornercase: if they are reliable). Also, it is not only make itself that has to take care of this, but also the little Perlhelpers etc that fiddle with this. IMHO, keeping the paths unixy is the safest bet. Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Patch] Code review fix
On Mon, Dec 05, 2011 at 05:26:00PM +0530, Muthu Subramanian K wrote: > During the code digging for one of the bugs, I came across GetXPixel() > function in vcl. Which seems to be implemented wrong - not sure why it > is multiplied by 257 - the idea, I believe, is to convert 8bit to 16bit > values for X11, but I may be wrong. I think that is the idea, too. But your patch means we will never output pure white. Let me explain. Each component in 8 bit is from 0 to 255 (0xFF). In 16 bits, from 0 to 65535 (0x). When converting, we want to map 00 to 0, and the maximum value to the maximum value. But your patch maps 255 to 65280 (0xFF00). So it maps pure white (RGB8 0xFF 0xFF 0xFF) to light grey (RGB16 0xFF00 0xFF00 0xFF00). OTOH, 255*257 is exactly 65535 :) Multiplying by 257 maps: 0x00 to 0x 0x01 to 0x0101 0x02 to 0x0202 .. 0xB3 to 0xB3B3 .. 0xFF to 0xFFF Giving a nice constant 16-bit difference between two consecutive 8-bit values. Maybe that code would be more clear if instead of "*257", it did something like "r<<8 + r" or "r<<8 | r"? Thanks for raising the question, tough. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build Libo - Error when execute ./autogen.sh
On Mon, Dec 05, 2011 at 09:07:45AM -0200, Alex Sandro Fagundes wrote: > I'm tried build libo, but I'm with problems how showed on annex. > I tried several forms, but not work. Have you installed the Windows Installer SDK? I think it is part of the Windows (Platform) SDK, but maybe it is not installed by default or you removed it from the list of components to be installed. Run the Windows SDK installer again and make sure you select the Windows Installer SDK component for installation. Have you already found the page http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies ? Just a small note: please try to send the error messages as text rather than graphic, it makes it much more convenient to read. Right-click on the console (or system menu / edit), choose "mark" (or similar: maybe select, not sure anymore), select what you want and press enter. Then go to your email and paste the error message in. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] Naming builds. Please???
Pedro Lino píše v So 03. 12. 2011 v 23:40 +: > Hi Lionel > > > Git commit IDs as identifiers have the huge problem that they are not > > comparable (one cannot say which one is "greater") without referring > > to the repository. How about we also put the *commit* (not author) > > timestamp (in UTC) of the top node (commit), and maybe the branch? > > That would help! > > > Something like: > > > > Build assembled from: > > repo commit date branch > > core: 4f11d0a 2011-11-16 21:57:28 master > > help: adcf6d5 2011-11-05 14:01:21 master > > ... > > > > Or instead of pretty-printing the date, just put it as seconds > > since the epoch: > > > > core: 4f11d0a 1321480648 master > > help: adcf6d5 1320501681 master > > That would solve the problem when looking into the log file but not > when looking at the About box. > > Picking up your (excellent) idea of using the date and converting to a > linear value: if each repository was given a Birth Date and time since > that date converted to a linear value (age), using the Date function > you could get a 10 digit value able to separate builds with one second > time difference. > > E.g. If the Core repository was created at midnight Sept 28th 2010 > (TDF's birthday) or in linear time (times 10 to eliminate the > point) 404490, then the 4f11d0a 2011-11-16 21:57:28 master > > age would be 41491490. This seems like a nice easy number to compare. > In fact a build using code from one second later would be 41491491. Hmm, we check out the five repositories one by one. It might take some time if you have slower network connection. There might be more commits in the other repositories in the meantime => the question is what time to use. We might end up with 5 times in the end, e.g.: 41491491-41491527-41491568-41491597-41491613 It is quite complex in the end. Also, it would be hard for developers to get the corresponding commit from it. I think that we should first define what we expect from the version number. Note that we could mention more lines in the about dialog. They are easy to cut&paste, so they should not cause troubles. I see the following needs and solutions: + easily match about dialog with downloaded tarball => we need to use the same string in both I would add one more line with a time generated by configure to the about dialog. The same time should be used in the download tarball name + easily match build with git commit => keep the git IDs in about dialog + human readable string for official builds for normal users: => I would add one more line, .e.g. 3.5.0-beta1 it will be used only in the official builds generated from release tarballs or release tags Does it make sense? Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Patch] Code review fix
Hi,
During the code digging for one of the bugs, I came across GetXPixel()
function in vcl. Which seems to be implemented wrong - not sure why it
is multiplied by 257 - the idea, I believe, is to convert 8bit to 16bit
values for X11, but I may be wrong. I have attached the patch with this
mail for review.
Thank you!
Muthu Subramanian
diff --git a/vcl/unx/generic/app/saldisp.cxx
b/vcl/unx/generic/app/saldisp.cxx
index 9ef3601..a92ed1d 100644
--- a/vcl/unx/generic/app/saldisp.cxx
+++ b/vcl/unx/generic/app/saldisp.cxx
@@ -3159,9 +3159,9 @@ inline sal_Bool SalColormap::GetXPixel( XColor
&rColor,
int g,
int b ) const
{
-rColor.red = r * 257;
-rColor.green= g * 257;
-rColor.blue = b * 257;
+rColor.red = r << 8;
+rColor.green= g << 8;
+rColor.blue = b << 8;
return XAllocColor( GetXDisplay(), m_hColormap, &rColor );
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Naming builds. Please???
On Mon, Dec 05, 2011 at 02:30:07AM -0800, Pedro wrote: > Stephan Bergmann-2 wrote >> Using pretty-printed dates would make it easier to disambiguate the >> seven-letter commit ID prefixes to the complete IDs (the commit >> date would help narrow done in which commit range to look for the >> given prefix). > May I argue that the Age code I propose on this topic fixes that > problem? > Since it is an age, there is no chance that in the future the code will > repeat itself. You may have missed that my "seconds since the epoch" (in my example: 1321480648) is also an age, and has mostly the same properties. It is somewhat longer than your format, since it takes an earlier epoch (the standard Unix epoch, 1 Jan 1970). I don't care strongly which epoch we take; IMHO the Unix epoch is a bit easier to handle since standard tools already know this format, but that's a pretty minor point. As to the question of pretty-printed date or "linear time / age", well... pretty-printed date is human-readable and familiar, but more complicated for my brain to read: 6 numbers instead of one. Then, pretty-printed date is easier (even for my brain) to *memorise*. I fear it is a question of taste. Formally, they give the same disambiguation power. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Fix rendering of GTK combobox in RTL
Thanks, pushed to master, will thus be in 3.5. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Build Libo - Error when execute ./autogen.sh
Hi, I'm tried build libo, but I'm with problems how showed on annex. I tried several forms, but not work. I tried: --with-jdk-home=/cygdrive/c/Program Files/Java/jdk1.6.0_25 --with-jdk-home="C:\DXSDK" --with-jdk-home="C:\Program Files\Microsoft SDKs\Windows\v6.0A" -- Att, Alex Sandro Fagundes Twitter: @alexsfagundes Email : alexsfagun...@gmail.com Fone: (47) 84459054 WEB SITE: www.descobrindoideias.com <>___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCHES] [PUSHED] Decoview cleanup - remove unneeded header
Pushed all six patches to master, will thus be in 3.5.0. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] setting the background color of an Edit
On Sun, 2011-12-04 at 19:05 +0100, Markus Mohrhard wrote: > It seems that does not work for an Edit. I can set the font color with > SetForegroundColor but the SetBackgroundColor has no effect. I now > solved the problem by changing the color of the FixedText I use for > the information text. That is not that nice but better than nothing > and I have not enough time to fix the bug. :-) in these cases, I'd (personally) tend to read the rendering code for the edit control: vcl/source/control/edit.cxx /ImplClearBackground/ is prolly your friend ;-) thanks for fixing the bug though ! HTH, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] "make dev-install -o build" does a complete incremental build
Hi, After "make" in top directory, one is suggested to do make dev-install -o build This used to skip the build and just do the dev-install part, but not anymore. That's rather annoying, as an incremental build that does nothing takes quite some time to notice it has to do nothing (and run unittests). Additionally, the incremental build (just after "make" successfully finished, no source file touched/changed) relinks quite some libraries and JCS/JAR files, I'm not sure why. That too is annoying in itself, and makes the above only worse. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Naming builds. Please???
Stephan Bergmann-2 wrote > > Using pretty-printed dates would make it easier to disambiguate the > seven-letter commit ID prefixes to the complete IDs if later commits > happen to introduce IDs with the same prefix (in which case the commit > date would help narrow done in which commit range to look for the given > prefix). (Not that the full Git IDs are unambiguous, either. But when > they start to clash, we are fucked, anyway.) > May I argue that the Age code I propose on this topic fixes that problem? Since it is an age, there is no chance that in the future the code will repeat itself. The truncated 7 letters of the SHA may happen to repeat (although the probability is possibly very low) Just a correction to my previous email: in ten years the core would be 4085.31260 which is easily distinguished from the current builds which are around 414.91491 Best regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Naming-builds-Please-tp3556898p3561011.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] a few more translations
Hi Mike, On Sun, 2011-12-04 at 09:37 -0800, Mike Whiteley wrote: > I am an American, but have lived in Germany for several > years. My German is pretty decent, but probably not fluent. Cool - it's really great to have you helping out and cleaning up the codebase. > I do not wish to debate , or have an argument on the finer > points of the meanings of some of these words: Sure; the big picture is a rather clear improvement - (at least for those of us not used to the finer nuances of German) ;-) > I am also a pretty experienced coder. Sometimes I will > stray from the literal meaning of the comment in order to > make the actual code more clear. If this is not preferred, > then I'll resist the urge to do that. Cool - are you particularly interested in hacking on a specific LibreOffice feature ? (if so we can help out with code pointers), or are you in more of a cleanup & while learning the code mode ? Also; as a final request - any chance of an explicit mail on licensing to the list: "all my contributions to LibreOffice are licensed under the MPL/LGPLv3+ dual license" or somesuch so we can link it into: http://wiki.documentfoundation.org/Development/Developers and not bother you in the future :-) Anyhow, thanks again, ATB, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] PostgreSQL-SDBC: enable by default on GNU/Linux, BSD
Hi, So, PostgreSQL-SDBC is now in libreoffice master branch, but not enabled by default. Let's enable it by default on "traditional" Unices (GNU/Linux, BSD, but not MacOS X yet), where we have a working internal libpq (PostgreSQL C client library), so no extra build dependency. I would be nice if tinderboxes for these platforms (i.e. only GNU/Linux AFAIK) would build it too, to get a bit more test coverage than my Debian box :) Do the tinderboxes just use distro-config/FOO or does this need manual intervention by the tinderbox operators? If enabling it breaks the tinderbox build (on a traditional Unix), warn me, I'll take care of it. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Translate German comments and correct some English ones
On Sat, 2011-12-03 at 00:08 +0100, Philipp Weissenbacher wrote: > >Lol :-) I think Bjoern is just joking - we're well rid of that mess. > > We'll soon re-discover the fragile bits of code after we change them in > > future ;-> > > Well I thought so already. Maybe we indeed should add a marker saying > exactly that? Nah - we should expunge all superstitious comments & as/when people change fragile code & create bugs, hopefully they will re-write it, if not - they'll create a bug, and the bug fixer (while getting ill reading it) will hopefully re-write it :-) > But then, what constitutes an old comment? Very often I found that the > "JP with a date" comments were obviously added _after_ the original > comment. Really - trying to detect and annotate fragile pieces of code with special comments is not a winning idea I think :-) so just carry on removing junk 'JP 12345' comments without any concern ... All the best, Michael -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Translate German comments and correct some English ones
Hi, From Björn's message: > Hmm, in the future, maybe just adding a "[very old comment]" to it could be > helpful. But no need to retroactively seek though old translations IMHO. Okay, won't do this then for Philipp's translations. Anyway, what constitutes a [very old comment], would that be anything before 2001? From Philipp's message: > But then, what constitutes an old comment? Very often I found that the > "JP with a date" comments were obviously added _after_ the original > comment. That's interesting. How do you determine that..? By seeing that there is a "conversation" in the comments (original comment > second comment about a change in behaviour)? Or because pointers to bugs are usually added later on when the product is already released? Or by some other means? > Maybe a "FIXME: Old comment" would be a good heads-up? I'm almost sure, not all our old code is bad, so there is probably a need to fix /all/ of it. > Also, the comments are literally littered with "!ACHTUNG: !" > and double question marks. What should we make of that? I'm not a fan of excessive punctuation, so I would just convert this to "Attention!"/"Caution!"/"Warning!", whatever seems appropriate. Astron. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] LibO 3.5.0 Beta 0 First assessment
> We plan to do the beta builds as dev builds, so they will be installed > in parallel with the stable release. Excellent news! Is this going to be included on the first Public Beta which is scheduled for today? > Though, the release candidates are going to replace the stable releases > on Windows and MAC. They still will install in parallel with 3.4 on > Linux. So, it will work the same way like with 3.4 vs. 3.3. Can't this be consistent across OSes? What option allows RCs to be installed in parallel in Linux? Can't we use the same option in Windows and Mac? Best regards, Pedro ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] XDG config migration
Hi guys, After updating to 3.5 quite few people reported that their configuration is gone and they have default setup. The reason for this is that 3.5 now uses XDG spec ~/.config/libreoffice instead of ~/.libreoffice. Simple copy of later folder to replace the former one solved the issued for everyone. In my humble opinion I think that this migration should be done automatically and user should not be bothered by this (even packagers should not do this as we should mostly NOT touch user homedirs). Cheers Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Naming builds. Please???
On 12/03/2011 10:16 PM, Lionel Elie Mamane wrote: Something like: Build assembled from: repo commit date branch core: 4f11d0a 2011-11-16 21:57:28 master help: adcf6d5 2011-11-05 14:01:21 master ... Or instead of pretty-printing the date, just put it as seconds since the epoch: core: 4f11d0a 1321480648 master help: adcf6d5 1320501681 master Using pretty-printed dates would make it easier to disambiguate the seven-letter commit ID prefixes to the complete IDs if later commits happen to introduce IDs with the same prefix (in which case the commit date would help narrow done in which commit range to look for the given prefix). (Not that the full Git IDs are unambiguous, either. But when they start to clash, we are fucked, anyway.) Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-qa] LibO 3.5.0 Beta 0 First assessment
Cor Nouws píše v So 03. 12. 2011 v 18:23 +0100: > Pedro Lino wrote (03-12-11 11:23) > > I hope that _at least_ they make DAMN sure that Beta1 doesn't > > overwrite the stable build... > > To be honest: I have no idea. I just install zillions (well, little less > ;-) ) without system integration. > But your question is relevant indeed. We plan to do the beta builds as dev builds, so they will be installed in parallel with the stable release. Though, the release candidates are going to replace the stable releases on Windows and MAC. They still will install in parallel with 3.4 on Linux. So, it will work the same way like with 3.4 vs. 3.3. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Bug 36874 page size incorrect when creating label document - help asked
I am trying to locate the source where the page size is determined when creating a new label document with the wizard. Although the dimensions in the label-definitions for A4 label sheets are correct, LibO creates a document with custom page format and not A4. I can't find where the document is created. Can anybody give me a hint? My goal is to see if it is an easy hack and in that case to provide a patch. Also, there seems to be a lot of duplicates for this bug. I have summarised them in my comment in bug 36874. Can anybody who knows how mark them as dumpicates? Thank you for your attention. Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] PostgreSQL-SDBC: Windows & MacOS X porters sought
Le 05/12/2011 00:22, Lionel Elie Mamane a écrit : Hi Lionel, So, PostgreSQL-SDBC is now in libreoffice master branch, but not enabled by default. We now need a developer with access to a Windows build and a developer with access to a MacOS X build to build and make the necessary adaptations, if any. Configure with: --enable-extension-integration --enable-ext-postgresql-sdbc Ideally, please test both --with-system-postgresl (or --with-libpq-path) and --without-system-postgresql (internal postgresql). I will attempt a build today on my MacOSX machine and keep you posted. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Bug 37361 depends on bug 42914, which changed state. Bug 42914 Summary: Terminal (command) window is opened when launching any executable https://bugs.freedesktop.org/show_bug.cgi?id=42914 What|Old Value |New Value Resolution||FIXED Status|REOPENED|RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Bug 37361 depends on bug 42979, which changed state. Bug 42979 Summary: Wrong application icon on the MSVC Master https://bugs.freedesktop.org/show_bug.cgi?id=42979 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Bug 37361 depends on bug 43454, which changed state. Bug 43454 Summary: Break-off with message "Terminate Quick Starter" https://bugs.freedesktop.org/show_bug.cgi?id=43454 What|Old Value |New Value Resolution||DUPLICATE Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] PostgreSQL-SDBC: Windows & MacOS X porters sought
On Mon, Dec 05, 2011 at 09:47:42AM +0200, Tor Lillqvist wrote:s >> and AFAIK, cygwin creates real Windows PE/COFF executables and >> libraries, no? > Executables built with the Cygwin gcc, for Cygwin, require the > Cygwin DLL and run inside the Cygwin Unix emulation (starting it if > not already running). Ah, I see. > Why can't you just trust that I know what I am talking about? I do trust you know what you are talking about, that's why I ask explanations of *you* to learn and understand. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Bug 37361 depends on bug 42826, which changed state. Bug 42826 Summary: unopkg.bin runtime error during installation https://bugs.freedesktop.org/show_bug.cgi?id=42826 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
