Re: Ctrl-Double-Click for sidebar. Is missing feature intended?
On 16.05.2013 19:21, Regina Henschel wrote: Hi, I'm writing texts about the sidebar window for the bundled help and come across this problem: The sidebar is a dockable window. Other windows of this kind like Navigator, StyleFormatting, Gallery, or Page Pane can be docked and undocked by Ctrl-Double-Click in a free part of the area under the title bar. The sidebar window does not have this feature, at least I cannot make it work. Is this intended or is it a bug? This has been fixed by issue 122321. -Andre Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: trunk: TOOLBOX_ITEM_HEIGHT redefined
On 17.05.2013 07:36, Pavel Janík wrote: On Apr 11, 2013, at 7:58 AM, Pavel Janík wrote: current trunk: Compiling: sc/source/ui/sidebar/NumberFormatPropertyPanel.cxx In file included from /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sc/source/ui/sidebar/NumberFormatPropertyPanel.cxx:28: ./NumberFormatPropertyPanel.hrc:45:1: error: TOOLBOX_ITEM_HEIGHT redefined In file included from /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sc/source/ui/sidebar/NumberFormatPropertyPanel.cxx:24: /Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/400/unxmacxi.pro/inc/sfx2/sidebar/propertypanel.hrc:94:1: error: this is the location of the previous definition dmake: Error code 1, while making '../../../unxmacxi.pro/slo/NumberFormatPropertyPanel.obj' ERROR: error 65280 occurred while making /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sc/source/ui/sidebar This is still the case in the current tree. As a workaround, I have this in my tree. Is this constant the same as in sfx2? Should it be the same value? Index: source/ui/sidebar/NumberFormatPropertyPanel.hrc === --- source/ui/sidebar/NumberFormatPropertyPanel.hrc (revision 1483653) +++ source/ui/sidebar/NumberFormatPropertyPanel.hrc (working copy) @@ -37,7 +37,7 @@ //===position= #define MBOX_WIDTH 28 -#defineTOOLBOX_ITEM_HEIGHT 12 +// #define TOOLBOX_ITEM_HEIGHT 12 #define CHECKBOX_HEIGHT 10 #define FT_CATEGORY_X SECTIONPAGE_MARGIN_HORIZONTAL This should make a difference because in sfx2/sidebar/ResourceDefinitions.hrcTOOLBOX_ITEM_HEIGHT is defined to be 15, not 12. But I tried both versions and can not see a difference. But still #undef TOOLBOX_ITEM_HEIGHT #define TOOLBOX_ITEM_HEIGHT 12 might be safer. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Several help-id for the same command
Hi, For some fields in the panels of the sidebar I see a new help-id. For example the drop-down-list for the line style has got the help-id SVX_HID_PROPERTYPANEL_LINE_TBX_STYLE. But the same list has already the help-id .uno:XLineStyle for the field in the classical toolbar and the help-id RID_SVXPAGE_LINE:LB:LINE_STYLE in the classical line property dialog. Is there a reason for different help-ids? I can map the new help-id to the existing help text, but I'm not sure whether I should do it. Or is it possible and better to use only one help-id? Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: trunk: TOOLBOX_ITEM_HEIGHT redefined
Hi Andre, This should make a difference because in sfx2/sidebar/ResourceDefinitions.hrcTOOLBOX_ITEM_HEIGHT is defined to be 15, not 12. But I tried both versions and can not see a difference. But still #undefTOOLBOX_ITEM_HEIGHT #define TOOLBOX_ITEM_HEIGHT 12 might be safer. This only hides the problem and makes the code looking strange. What about using different name/prefix or something other? -- Pavel Janík - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: trunk: TOOLBOX_ITEM_HEIGHT redefined
On 17.05.2013 09:44, Pavel Janík wrote: Hi Andre, This should make a difference because in sfx2/sidebar/ResourceDefinitions.hrcTOOLBOX_ITEM_HEIGHT is defined to be 15, not 12. But I tried both versions and can not see a difference. But still #undef TOOLBOX_ITEM_HEIGHT #define TOOLBOX_ITEM_HEIGHT 12 might be safer. This only hides the problem and makes the code looking strange. What about using different name/prefix or something other? I would prefer the 'something other' option: refactor the definition of positions of the number format panel. But I don't have the time for it right now. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: trunk: TOOLBOX_ITEM_HEIGHT redefined
On May 17, 2013, at 9:49 AM, Andre Fischer wrote: On 17.05.2013 09:44, Pavel Janík wrote: Hi Andre, This should make a difference because in sfx2/sidebar/ResourceDefinitions.hrcTOOLBOX_ITEM_HEIGHT is defined to be 15, not 12. But I tried both versions and can not see a difference. But still #undef TOOLBOX_ITEM_HEIGHT #define TOOLBOX_ITEM_HEIGHT 12 might be safer. This only hides the problem and makes the code looking strange. What about using different name/prefix or something other? I would prefer the 'something other' option: refactor the definition of positions of the number format panel. But I don't have the time for it right now. Well, yes. But... This constant is used in three files in sidebar directory: source/ui/sidebar/AlignmentPropertyPanel.hrc:#define FT_LEFTINDENT_Y (ALIGNMENT_Y + TOOLBOX_ITEM_HEIGHT + TBX_OUT_BORDER_OFFSET_Y + CONTROL_SPACING_VERTICAL) source/ui/sidebar/AlignmentPropertyPanel.src: Size = MAP_APPFONT ( TOOLBOX_ITEM_WIDTH * 3 , TOOLBOX_ITEM_HEIGHT) ; source/ui/sidebar/NumberFormatPropertyPanel.hrc:#define TOOLBOX_ITEM_HEIGHT 12 source/ui/sidebar/NumberFormatPropertyPanel.hrc:#define FT_DECIMALS_Y TBX_CATEGORY_Y + TOOLBOX_ITEM_HEIGHT + 4 + CONTROL_SPACING_VERTICAL In the first case, it's value is 15, in the second case it is 12. This will lead to some error in the near future... So is this the right solution? sed -i 's#TOOLBOX_ITEM_HEIGHT#LOCAL_TOOLBOX_ITEM_HEIGHT#' source/ui/sidebar/NumberFormatPropertyPanel.hrc -- Pavel Janík - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Several help-id for the same command
On 17 May 2013 09:38, Regina Henschel rb.hensc...@t-online.de wrote: Hi, For some fields in the panels of the sidebar I see a new help-id. For example the drop-down-list for the line style has got the help-id SVX_HID_PROPERTYPANEL_LINE_**TBX_STYLE. But the same list has already the help-id .uno:XLineStyle for the field in the classical toolbar and the help-id RID_SVXPAGE_LINE:LB:LINE_STYLE in the classical line property dialog. Is there a reason for different help-ids? I can map the new help-id to the existing help text, but I'm not sure whether I should do it. Or is it possible and better to use only one help-id? If there are reason to have different help-ids (which I cannot judge), the best would be to use only 1 help-id, especially when we think a bit ahead to the time where we replace the help system. rgds jan I. Kind regards Regina --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: trunk: TOOLBOX_ITEM_HEIGHT redefined
On 17.05.2013 10:02, Pavel Janík wrote: On May 17, 2013, at 9:49 AM, Andre Fischer wrote: On 17.05.2013 09:44, Pavel Janík wrote: Hi Andre, This should make a difference because in sfx2/sidebar/ResourceDefinitions.hrcTOOLBOX_ITEM_HEIGHT is defined to be 15, not 12. But I tried both versions and can not see a difference. But still #undef TOOLBOX_ITEM_HEIGHT #define TOOLBOX_ITEM_HEIGHT 12 might be safer. This only hides the problem and makes the code looking strange. What about using different name/prefix or something other? I would prefer the 'something other' option: refactor the definition of positions of the number format panel. But I don't have the time for it right now. Well, yes. But... This constant is used in three files in sidebar directory: source/ui/sidebar/AlignmentPropertyPanel.hrc:#define FT_LEFTINDENT_Y (ALIGNMENT_Y + TOOLBOX_ITEM_HEIGHT + TBX_OUT_BORDER_OFFSET_Y + CONTROL_SPACING_VERTICAL) source/ui/sidebar/AlignmentPropertyPanel.src: Size = MAP_APPFONT ( TOOLBOX_ITEM_WIDTH * 3 , TOOLBOX_ITEM_HEIGHT) ; source/ui/sidebar/NumberFormatPropertyPanel.hrc:#define TOOLBOX_ITEM_HEIGHT 12 source/ui/sidebar/NumberFormatPropertyPanel.hrc:#define FT_DECIMALS_Y TBX_CATEGORY_Y + TOOLBOX_ITEM_HEIGHT + 4 + CONTROL_SPACING_VERTICAL In the first case, it's value is 15, in the second case it is 12. This will lead to some error in the near future... So is this the right solution? sed -i 's#TOOLBOX_ITEM_HEIGHT#LOCAL_TOOLBOX_ITEM_HEIGHT#' source/ui/sidebar/NumberFormatPropertyPanel.hrc Yes, looks good. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: WaE: LineJoint_MAKE_FIXED_SIZE
Hi Pavel, On 17.05.2013 07:37, Pavel Janík wrote: On Apr 19, 2013, at 11:02 AM, Pavel Janík wrote: On Apr 19, 2013, at 10:51 AM, Armin Le Grand wrote: I am confused; where does com::sun::star::drawing::LineJoint_MAKE_FIXED_SIZE come from? When you look at he UNO API file (trunk\main\offapi\com\sun\star\drawing\LineJoint.idl) there is no such definition. Since the headers are generated from the UNO API files I would wonder if we have such a token at all. I do not know, the compiler should know better ;-) solver/400/unxmacxi.pro/inc/offuh/com/sun/star/drawing/LineJoint.hdl: LineJoint_MAKE_FIXED_SIZE = SAL_MAX_ENUM I added missing cases to the code today. Okay, thanks. Still - where does it come from and who uses this? The *.hdl is crerated form the *.idl normally AFAIK. I'll have a look now... Greetings Armin -- ALG - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Several help-id for the same command
On 17.05.2013 09:38, Regina Henschel wrote: Hi, For some fields in the panels of the sidebar I see a new help-id. For example the drop-down-list for the line style has got the help-id SVX_HID_PROPERTYPANEL_LINE_TBX_STYLE. But the same list has already the help-id .uno:XLineStyle for the field in the classical toolbar and the help-id RID_SVXPAGE_LINE:LB:LINE_STYLE in the classical line property dialog. Is there a reason for different help-ids? Yes, but not a good one. The two line style drop downs (toolbar and panel) look the same but at the moment they have different implementations. The panel implementation has been migrated from Symphony, together with the help id. But if it is possible for the help system, then we should use the toolbar help id and drop the panel help id. Both drop downs (should) look and behave identical and therefore should have the same help. I can map the new help-id to the existing help text, but I'm not sure whether I should do it. Or is it possible and better to use only one help-id? Please go ahead and remove or map the panel help id. -Andre Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: WaE: LineJoint_MAKE_FIXED_SIZE
Hi Pavel,
On 17.05.2013 10:24, Armin Le Grand wrote:
Hi Pavel,
On 17.05.2013 07:37, Pavel Janík wrote:
On Apr 19, 2013, at 11:02 AM, Pavel Janík wrote:
On Apr 19, 2013, at 10:51 AM, Armin Le Grand wrote:
I am confused; where does
com::sun::star::drawing::LineJoint_MAKE_FIXED_SIZE come from? When
you look at he UNO API file
(trunk\main\offapi\com\sun\star\drawing\LineJoint.idl) there is no
such definition. Since the headers are generated from the UNO API
files I would wonder if we have such a token at all.
I do not know, the compiler should know better ;-)
solver/400/unxmacxi.pro/inc/offuh/com/sun/star/drawing/LineJoint.hdl: LineJoint_MAKE_FIXED_SIZE
= SAL_MAX_ENUM
I added missing cases to the code today.
Okay, thanks. Still - where does it come from and who uses this? The
*.hdl is crerated form the *.idl normally AFAIK. I'll have a look now...
Looks as if for all *.hdl files which define enums the idl compiler
generates a last entry in the form of
enum tag
{
...
tag_MAKE_FIXED_SIZE = SAL_MAX_ENUM
};
Thus, all is fine, no unused/new/unexpected entry. From the C++
perspective it's questionable when this leads to extra-code in
switch/case statements for an entry which seems to be there for UNO
technical reasons to be warning-free. Those entries have no
informational content as it seems.
Greetings
Armin
--
ALG
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [buildbot] investigate nightly windows build
Hi, On 17.05.2013 01:53, Andrew Rist wrote: our buildbot building trunk nightly for windows has problems in modul apr since a couple of days. Unfortunately, the log does provide nothing for a reason not known to me. Thus, I will try to investigate the problem. Hopefully, I can change the buildbot script to get the build output directly on stdout instead of as html. The html output is currently not containing the corresponding information about the build of module apr. Done and Thx to Herbert triggering a clean build. Unfortunately, the build was successful. Thus, I assume the reason that we had no nightly windows builds from trunk since 2013-04-28 was that no clean build had been performed. This is not the case. The clean build is not the panacea you see it as. As mentioned in several other communications, I went onto the box and cleaned up some processes that were hung (win7, win7snap, and win7ia2). All built successfully - even though the other two were incremental. The hung processes tend to occur /more/ during clean builds - not all the time, just more often. Thus, clean builds are more likely to create this type of build failure, they are not a fix as you're suggesting. Thanks for the information. In order to have something more tangible for fixing this defect of hanging build processes I propose to start an corresponding investigation. At least we should have a look after each build, esp. after each clean build, if there are processes which hang. It seems that this defect just occured with build #105 of aoo-w7ia2 - see [1]. The build had been killed. I assume that the one or the other process of this build is still working. Can somebody with corresponding karma check, if there are again hanging processes? [1] http://ci.apache.org/builders/aoo-w7ia2/builds/105 The build was not killed - the process that was running didn't report back in 12000 sec = 200 min or 3+hours At that point the buildbot tries to clean up, but this is the reaction, not the root cause. command timed out: 12000 seconds without output, killing pid 2472 SIGKILL failed to kill process using fake rc=-1 program finished with exit code -1 That is what I meant by killed - sorry for not expressing myself clear. When I checked it later, the process was still hung (thus it's unlikely that our problem is just with the length of the timeout). This is what one of these hung processes looks like, and any subsequent builds will fail if it's not cleaned up, as the processes lock files and block subsequent compiles of the same package. Thanks for having a look. Build #106 of aoo-w7ia2 went well after your clean up. Unfortunately, build #107 of aoo-w7ia2 had again the same failure as build #105. Best regards, Oliver. Best regards, Oliver. Andrew, can only you perform such an investigation, because (as far as I know) you are the only who have direct access on the machine? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [buildbot] investigate nightly windows build
Hi, On 17.05.2013 01:57, Andrew Rist wrote: our buildbot building trunk nightly for windows has problems in modul apr since a couple of days. Unfortunately, the log does provide nothing for a reason not known to me. Thus, I will try to investigate the problem. Hopefully, I can change the buildbot script to get the build output directly on stdout instead of as html. The html output is currently not containing the corresponding information about the build of module apr. Done and Thx to Herbert triggering a clean build. Unfortunately, the build was successful. Thus, I assume the reason that we had no nightly windows builds from trunk since 2013-04-28 was that no clean build had been performed. This is not the case. The clean build is not the panacea you see it as. As mentioned in several other communications, I went onto the box and cleaned up some processes that were hung (win7, win7snap, and win7ia2). All built successfully - even though the other two were incremental. The hung processes tend to occur /more/ during clean builds - not all the time, just more often. Thus, clean builds are more likely to create this type of build failure, they are not a fix as you're suggesting. Thanks for the information. In order to have something more tangible for fixing this defect of hanging build processes I propose to start an corresponding investigation. Sounds good... thx, for the +1 At least we should have a look after each build, esp. after each clean build, if there are processes which hang. Andrew, can only you perform such an investigation, because (as far as I know) you are the only who have direct access on the machine? This I am not signing up for - I can't really commit to having the time to focus on this. I will help interacting with infra to get access for any committer that wants to take this on.. (I will look next time we get one of these and at least specifically identify what process is hanging and post that back, but I am afraid the debugging of the stack is going to be a bit more involved) Sorry, again a misunderstanding. I just wanted to know, if currently only you had the karma to perform such an investigation - I did not meant that you have to perform it. Thus, it would be great (and needed), that one or two or three volunteers show up in order to take responsibility here. Thanks to Andrew for the offer to interact with infra for getting the karma for these volunteers. Who has interest to take responsibility here? Best regards, Oliver. A. Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
introduction
this is Prof Mervat Hamdy faculty of medicine-Cairo university Egypt we are going to shift some modules off our curriculum to e-modules that is why and i am interested to know about the technology media used to be familiar with and start up such work for the faculty. thanks -- -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify it-u...@kasralainy.edu.eg. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the faculty. Finally, the recipient should check this email and any attachments for the presence of viruses. The faculty accepts no liability for any damage caused by any virus transmitted by this email. (c)Kasralainy Faculty of Medicine, Cairo University, Egypt www.kasralainy.edu.eg
Re: WaE: LineJoint_MAKE_FIXED_SIZE
On 17.05.2013 11:08, Pavel Janík wrote: Thus, all is fine, no unused/new/unexpected entry. From the C++ perspective it's questionable when this leads to extra-code in switch/case statements for an entry which seems to be there for UNO technical reasons to be warning-free. Those entries have no informational content as it seems. Right. Should I change them to default: break; instead? Maybe better, makes things clearar from my POV - +1 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Writing script for compilation AOO on GNU/Linux
Hi I am writing a script [1] for compilation AOO on GNU/Linux. 1 - https://github.com/binoanb/scripts/blob/master/compilar_aoo4.sh It's still very fresh and needs several improvements. I started yesterday. -- Albino B Neto albinopcs.wordpress.com twitter.com/binoanb www.debian.org Chave GPG: 5ED34354 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[QA][Test Report] Weekly Status Update as of 20130517
Hi All, We continue doing the AOO 4.0 Full Regression test this week, here is the weekly update (5/12 - 5/17), please find more detail statistics in wiki: http://wiki.openoffice.org/wiki/QA/Report/WeeklyReport/20130517 *Test execution:* We have assigned 1062 text executions to about 16 volunteers(6 more this week), and completed about 41% in execution so far. All Redhat test executions have been assigned to Open Client Linux test team joined this week (Thansk John Walicki and Donald Harbison!). Most of Mac test executions have not been assigned yet (only 1 volunteer so far). *Defect summary:* 1. 24 defects were opened and 23 defect were resolved last week, so we have 1 (24-23) net new defect added in the backlog 2. In backlog, nearly 700 - 800 defects are critical candidate defects - Volunteers are being assigned to work with the unconfirmed ones, this is our top-priority work item * Issues quality highlight:* 1. Critical defects are waiting for fix - need more Dev volunteers to involve 2. Redhat is with risk as less testing on it - need more QA volunteers who can provide testing on this platform 3. QAs are reminded to make sure to perform all test cases with navigation and accelerators, and make sure to specify defect numbers in Testlink for failed test executions * Volunteer status: * 1. We have 5 more volunteers from Open Client Linux test team to cover Redhat, and 1 more for Mac, it would be great to have more volunteers on Mac 2. We have total 4 vulunteers on defect work, need more to clean backlog of unconfirmed and resolved defects * Plan for next week:* 1. Prioritize critical defects and assign them to Dev volunteers 2. Confirm critical defects which are not confirmed yet 3. Continue AOO 4.0 Full Regression test Thanks you all for effort this week, let's continue and make progress next week! Regards, Yu Zhen
Re: introduction
On Fri, May 17, 2013 at 5:51 AM, Mervat Hamdy Abdel Salam Abdel-Nabi mervatha...@kasralainy.edu.eg wrote: this is Prof Mervat Hamdy faculty of medicine-Cairo university Egypt we are going to shift some modules off our curriculum to e-modules that is why and i am interested to know about the technology media used to be familiar with and start up such work for the faculty. Hello Professor Mervat Hamdy, A quick review of the technology we offer. Apache OpenOffice is a free, open-source office productivity suite that runs on the Windows, Mac and Linux operating systems. It is available in many languages, including Arabic. Our applications include a word processor, spreadsheet, presentation graphics, database front end, vector graphics drawing tool and a mathematical equation editor. We work well with OpenDocument Format and Microsoft file formats, and we export to PDF. Depending on the form of your existing curriculum materials, it might work well to convert them into text documents (with diagrams and images) or presentation documents, and then host these materials on a website in PDF format. You can find more information about OpenOffice capabilities here: http://www.openoffice.org/product/index.html Regards, -Rob thanks -- -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify it-u...@kasralainy.edu.eg. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the faculty. Finally, the recipient should check this email and any attachments for the presence of viruses. The faculty accepts no liability for any damage caused by any virus transmitted by this email. (c)Kasralainy Faculty of Medicine, Cairo University, Egypt www.kasralainy.edu.eg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Translators needed for Wizard Templates Titles
Dňa Thu, 16 May 2013 15:03:47 +0200 Ariel Constenla-Haile arie...@apache.org napísal: On Fri, Sep 28, 2012 at 02:47:11AM -0300, Ariel Constenla-Haile wrote: On Sat, Aug 25, 2012 at 07:02:18PM -0300, Ariel Constenla-Haile wrote: Hello *, Bug 110378 https://issues.apache.org/ooo/show_bug.cgi?id=110378 found a total of 292 templates without localized Title, in 11 Languages (es, eu, fr, it, ja, ko, pt-BR, sk, sv, zh-CN, zh-TW). The affected languages are: - Currently supported languages: * es, Spanish * fr, French * it, Italian * ja, Japanese * pt-BR, Portugese (Brazil) * sk, Slovak * zh-CN, Chinese (simplified) * zh-TW, Chinese (traditional) - Currently unsupported languages: * eu, Basque * ko, Korean * sv, Swedish Translations are still needed for - Chinese (traditional) - Portugese (Brazil) The translation is rather simple, almost 20/30 words, of kind Orange, Classic, Modern. Just a reminder that (after more than 8 months) translations are still missing. Regards Ariel, I don't understand the file for Slovak in the Bug 110378 is translated (or it is translated bad ?). The Fax Wizard in OOo341 don't has blank fields. Templates in source code ../openoffice/trunk/main/extras/source/templates/wizard/.. looks translated too. I missed something? Regards, Michal Hriň - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Translators needed for Wizard Templates Titles
Hi Michal, On Fri, May 17, 2013 at 10:40 AM, Michal Hriň michalh...@aol.com wrote: Translations are still needed for - Chinese (traditional) - Portugese (Brazil) The translation is rather simple, almost 20/30 words, of kind Orange, Classic, Modern. Ariel, I don't understand the file for Slovak in the Bug 110378 is translated (or it is translated bad ?). The Fax Wizard in OOo341 don't has blank fields. Templates in source code ../openoffice/trunk/main/extras/source/templates/wizard/.. looks translated too. I missed something? No, your translation is complete. Above, Translations are still needed for marks the missing translations. Regards - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Need QA (test) volunteers on Mac
It looks like the QA team is making great progress with testing Apache OpenOffice 4.0 on Windows. But they need more help on Mac. Another few volunteers would make a big difference here. We're looking for people who can spend a few hours over the next week or two to run specific, pre-defined test cases their Mac, and to enter Bugzilla issues for any failed test cases. This is a nice, gentle introduction to formal QA. No previous experience with QA is necessary, though good familiarity with OpenOffice from a user perspective is recommended. If you can help, please send a note to the QA mailing list at: q...@openoffice.apache.org Thanks! -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Need QA (test) volunteers on Mac
I think the prerequisite for the volunteers is to have a Mac machine. I do not have a mac machine. Can I volunteer? With Warm Regards V.Kadal Amutham 919444360480 914422396480 On 17 May 2013 19:52, Rob Weir robw...@apache.org wrote: It looks like the QA team is making great progress with testing Apache OpenOffice 4.0 on Windows. But they need more help on Mac. Another few volunteers would make a big difference here. We're looking for people who can spend a few hours over the next week or two to run specific, pre-defined test cases their Mac, and to enter Bugzilla issues for any failed test cases. This is a nice, gentle introduction to formal QA. No previous experience with QA is necessary, though good familiarity with OpenOffice from a user perspective is recommended. If you can help, please send a note to the QA mailing list at: q...@openoffice.apache.org Thanks! -Rob - To unsubscribe, e-mail: users-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-h...@openoffice.apache.org
Re: Need QA (test) volunteers on Mac
On Fri, May 17, 2013 at 10:44 AM, Kadal Amutham vka...@gmail.com wrote: I think the prerequisite for the volunteers is to have a Mac machine. I do not have a mac machine. Can I volunteer? There are still tests that need to be run on Windows and Linux as well, if you want to help there. But our larges gap currently is on Mac. -Rob With Warm Regards V.Kadal Amutham 919444360480 914422396480 On 17 May 2013 19:52, Rob Weir robw...@apache.org wrote: It looks like the QA team is making great progress with testing Apache OpenOffice 4.0 on Windows. But they need more help on Mac. Another few volunteers would make a big difference here. We're looking for people who can spend a few hours over the next week or two to run specific, pre-defined test cases their Mac, and to enter Bugzilla issues for any failed test cases. This is a nice, gentle introduction to formal QA. No previous experience with QA is necessary, though good familiarity with OpenOffice from a user perspective is recommended. If you can help, please send a note to the QA mailing list at: q...@openoffice.apache.org Thanks! -Rob - To unsubscribe, e-mail: users-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Critique of the Help/About box
On 5/13/13 9:24 AM, Jürgen Schmidt wrote: On 5/9/13 9:11 PM, Ariel Constenla-Haile wrote: On Thu, May 09, 2013 at 02:11:31PM -0400, Rob Weir wrote: It can still have some meaning: suppose someone in the ecosystem is building custom versions of AOO for their customers, they may want to configure with --with-vendor; they can even change the images in the dialog to whatever suits them (anyone can try this by changing the PNGs in the folder where the main executable file resides, about.png is the header of the dialog, logo.png is the main logo at the left), for example: http://people.apache.org/~arielch/images/AboutDialogCustomImg.jpg I can certainly see it being useful for someone else who builds a customized version of AOO. But that's not us. We're not *based on* Apache OpenOffice. We *are* Apache OpenOffice. This is confusing. Remember, we're trying to educate users to download safely, and use trusted downloads that continue Apache OpenOffice. So saying that we're based on OpenOffice is weird. That resource string can be split in several parts, and have two versions for that particular one: This product was created by %OOOVENDOR, based on Apache OpenOffice.\n used if -DOOO_VENDOR is passed to the compiler This product was created by %OOOVENDOR used if -DOOO_VENDOR is not passed. %OOOVENDOR is still needed as it makes branding easier. Another thing to think about, is taking out of the string the parts that don't need translation. For example, in Copyright © 2012 Apache Software Foundation.\n In some languages, they have translated Software Foundation, in others not; in some they have translated Copyright, in others not. We can state clearly what is supposed to be translated and what not. vid. http://opengrok.adfinis-sygroup.org/source/search?q=ABOUT_STR_COPYRIGHTdefs=refs=path=extras%2Fl10n%2Fsource%2Fhist=project=aoo-AOO34 that make a lot of sense and I agree that we should change the About dialog. Ariel created a further issue regarding the README and this changes make sense as well. I will trigger a (hopefully last) minor translation update for both changes when the fixes are in place. It's probably also a good idea to collect all this release relevant items that have to be checked for every relase. An up-to-date README is useful for the interested user. Or we move every changing content out of the file and on a easy to change webpage where we have more flexibility. I worked on this and split the string in several parts and insert some dependencies. See also the comments in the issue that I won't repeat all here. The main Copyright string will not be translated (the green marked string in the screenshots). We will have now 2 versions 1. default version if vendor is Apache Software Foundation http://people.apache.org/~jsc/screenshots/About_default.png 2. if the vendor is somebody else http://people.apache.org/~jsc/screenshots/About_vendor.png The wording can still be tuned and I am open to any suggestions until Tuesday. The copyright year is fixed for our default (at the moment 2013) and will set at build time when the vendor changed. This will probably changed in the future and the date will move into the openoffice.lst Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Critique of the Help/About box
On 5/17/13 6:03 PM, Jürgen Schmidt wrote: On 5/13/13 9:24 AM, Jürgen Schmidt wrote: On 5/9/13 9:11 PM, Ariel Constenla-Haile wrote: On Thu, May 09, 2013 at 02:11:31PM -0400, Rob Weir wrote: It can still have some meaning: suppose someone in the ecosystem is building custom versions of AOO for their customers, they may want to configure with --with-vendor; they can even change the images in the dialog to whatever suits them (anyone can try this by changing the PNGs in the folder where the main executable file resides, about.png is the header of the dialog, logo.png is the main logo at the left), for example: http://people.apache.org/~arielch/images/AboutDialogCustomImg.jpg I can certainly see it being useful for someone else who builds a customized version of AOO. But that's not us. We're not *based on* Apache OpenOffice. We *are* Apache OpenOffice. This is confusing. Remember, we're trying to educate users to download safely, and use trusted downloads that continue Apache OpenOffice. So saying that we're based on OpenOffice is weird. That resource string can be split in several parts, and have two versions for that particular one: This product was created by %OOOVENDOR, based on Apache OpenOffice.\n used if -DOOO_VENDOR is passed to the compiler This product was created by %OOOVENDOR used if -DOOO_VENDOR is not passed. %OOOVENDOR is still needed as it makes branding easier. Another thing to think about, is taking out of the string the parts that don't need translation. For example, in Copyright © 2012 Apache Software Foundation.\n In some languages, they have translated Software Foundation, in others not; in some they have translated Copyright, in others not. We can state clearly what is supposed to be translated and what not. vid. http://opengrok.adfinis-sygroup.org/source/search?q=ABOUT_STR_COPYRIGHTdefs=refs=path=extras%2Fl10n%2Fsource%2Fhist=project=aoo-AOO34 that make a lot of sense and I agree that we should change the About dialog. Ariel created a further issue regarding the README and this changes make sense as well. I will trigger a (hopefully last) minor translation update for both changes when the fixes are in place. It's probably also a good idea to collect all this release relevant items that have to be checked for every relase. An up-to-date README is useful for the interested user. Or we move every changing content out of the file and on a easy to change webpage where we have more flexibility. I worked on this and split the string in several parts and insert some dependencies. See also the comments in the issue that I won't repeat all here. The main Copyright string will not be translated (the green marked string in the screenshots). We will have now 2 versions 1. default version if vendor is Apache Software Foundation http://people.apache.org/~jsc/screenshots/About_default.png 2. if the vendor is somebody else http://people.apache.org/~jsc/screenshots/About_vendor.png The wording can still be tuned and I am open to any suggestions until Tuesday. The copyright year is fixed for our default (at the moment 2013) and will set at build time when the vendor changed. This will probably changed in the future and the date will move into the openoffice.lst correcting myself the portion copyright... in 2 should be moved in the next line always. And All rights reserved should be probably removed in both. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Need QA (test) volunteers on Mac
I can help on linux. I am using Ubuntu 11.1. This machine has libreoffice. I tried to install AOO, but could not. This issue should be addressed, But I can install in XP - windows and test With Warm Regards V.Kadal Amutham 919444360480 914422396480 On 17 May 2013 20:40, Rob Weir robw...@apache.org wrote: On Fri, May 17, 2013 at 10:44 AM, Kadal Amutham vka...@gmail.com wrote: I think the prerequisite for the volunteers is to have a Mac machine. I do not have a mac machine. Can I volunteer? There are still tests that need to be run on Windows and Linux as well, if you want to help there. But our larges gap currently is on Mac. -Rob With Warm Regards V.Kadal Amutham 919444360480 914422396480 On 17 May 2013 19:52, Rob Weir robw...@apache.org wrote: It looks like the QA team is making great progress with testing Apache OpenOffice 4.0 on Windows. But they need more help on Mac. Another few volunteers would make a big difference here. We're looking for people who can spend a few hours over the next week or two to run specific, pre-defined test cases their Mac, and to enter Bugzilla issues for any failed test cases. This is a nice, gentle introduction to formal QA. No previous experience with QA is necessary, though good familiarity with OpenOffice from a user perspective is recommended. If you can help, please send a note to the QA mailing list at: q...@openoffice.apache.org Thanks! -Rob - To unsubscribe, e-mail: users-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-h...@openoffice.apache.org - To unsubscribe, e-mail: users-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-h...@openoffice.apache.org
Re: Critique of the Help/About box
On Fri, May 17, 2013 at 12:03 PM, Jürgen Schmidt jogischm...@gmail.com wrote: On 5/13/13 9:24 AM, Jürgen Schmidt wrote: On 5/9/13 9:11 PM, Ariel Constenla-Haile wrote: On Thu, May 09, 2013 at 02:11:31PM -0400, Rob Weir wrote: It can still have some meaning: suppose someone in the ecosystem is building custom versions of AOO for their customers, they may want to configure with --with-vendor; they can even change the images in the dialog to whatever suits them (anyone can try this by changing the PNGs in the folder where the main executable file resides, about.png is the header of the dialog, logo.png is the main logo at the left), for example: http://people.apache.org/~arielch/images/AboutDialogCustomImg.jpg I can certainly see it being useful for someone else who builds a customized version of AOO. But that's not us. We're not *based on* Apache OpenOffice. We *are* Apache OpenOffice. This is confusing. Remember, we're trying to educate users to download safely, and use trusted downloads that continue Apache OpenOffice. So saying that we're based on OpenOffice is weird. That resource string can be split in several parts, and have two versions for that particular one: This product was created by %OOOVENDOR, based on Apache OpenOffice.\n used if -DOOO_VENDOR is passed to the compiler This product was created by %OOOVENDOR used if -DOOO_VENDOR is not passed. %OOOVENDOR is still needed as it makes branding easier. Another thing to think about, is taking out of the string the parts that don't need translation. For example, in Copyright © 2012 Apache Software Foundation.\n In some languages, they have translated Software Foundation, in others not; in some they have translated Copyright, in others not. We can state clearly what is supposed to be translated and what not. vid. http://opengrok.adfinis-sygroup.org/source/search?q=ABOUT_STR_COPYRIGHTdefs=refs=path=extras%2Fl10n%2Fsource%2Fhist=project=aoo-AOO34 that make a lot of sense and I agree that we should change the About dialog. Ariel created a further issue regarding the README and this changes make sense as well. I will trigger a (hopefully last) minor translation update for both changes when the fixes are in place. It's probably also a good idea to collect all this release relevant items that have to be checked for every relase. An up-to-date README is useful for the interested user. Or we move every changing content out of the file and on a easy to change webpage where we have more flexibility. I worked on this and split the string in several parts and insert some dependencies. See also the comments in the issue that I won't repeat all here. The main Copyright string will not be translated (the green marked string in the screenshots). We will have now 2 versions 1. default version if vendor is Apache Software Foundation http://people.apache.org/~jsc/screenshots/About_default.png 2. if the vendor is somebody else http://people.apache.org/~jsc/screenshots/About_vendor.png The wording can still be tuned and I am open to any suggestions until Tuesday. The copyright year is fixed for our default (at the moment 2013) and will set at build time when the vendor changed. This will probably changed in the future and the date will move into the openoffice.lst Would it be possible to have some space between each paragraph, e.g., a blank line before The OpenOffice community acknowledges... -Rob Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Next Plan for AOO 4.0 Testing
On May 15, 2013 1:29 AM, Yuzhen Fan fanyuz...@gmail.com wrote: Kay, It's confirmed that we don't have Base test cases in place so far, Draw is the same case. I agree with Rob that we define structured tests from now to have consistent coverage. We (Liu Ping and I) can initial a test matrix to organize test cases, and then call volunteers to populate the test matrix by writing test cases in TestLink. It is welcome if you can help on writing test cases. Thanks! Regards, Yu Zhen Hi Yu Zhen and thanks for this reply. I would love to help write test cases for Base at some point, but I don't have any training in QA, so I would definitely need some instruction from somewhere on how to go about this. I think the biggest hurdle with base testing is the availability of live DBs for connectivity testing. Some of us would readily be able to set something up, whereas others not. This would need to be some set of servers I would think that would house an ongoing set of tables for connectivity testing for any release. So, how can we make this happen? We probably need an additional thread for that discussion. On Wed, May 15, 2013 at 12:23 AM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, May 14, 2013 at 5:29 AM, Rob Weir robw...@apache.org wrote: On Sun, May 12, 2013 at 6:52 PM, Kay Schenk kay.sch...@gmail.com wrote: On Mon, May 6, 2013 at 4:40 AM, Yuzhen Fan fanyuz...@gmail.com wrote: (Added dev in this mail thread ..) Simon and all, Here is the update of the preparation for full regression: - All test cases are populated to test plan AOO 4.0 Full Regression Test in TestLink - Test guidance for Full Regression Test and Defect Verification are ready and have published in wiki https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Full+Regression+Test+Guidance https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Defect+Verification+Guidance - Defect verification list are generated per different products with multiple queries Thanks Liu Ping to make defect queries. Thanks Simon for guidance and reviewing all preparation work above. Regards, Yu Zhen I thought I might like to help with this. I'm interested in testing Base portions, but, I don't see any tests that apply to Base. Are there any? Test cases in Testlink are derived from the test cases used for Symphony. But Symphony did not include Base. So if we want structured testing of Base we'll need someone (or several people) to write some test cases. Or we could do informal, use-based testing like we did with 3.4./3.4.1. But best to get some tests defined so we can have consistent coverage. That will require that someone with expertise as a Base user step up to lead this. Regards, -Rob OK...this is what I figured after a while. The big problem with testing for Base is the availability of a test DB(s) to test connectivity in some way -- our indigenous MySQL connector, jdbc etc. Any ideas about that? On Mon, May 6, 2013 at 7:25 PM, Yuzhen Fan fanyuz...@gmail.com wrote: Simon and all, Here is the update of the preparation for full regression: - All test cases are populated to test plan AOO 4.0 Full Regression Test in TestLink - Test guidance for the Full Regression Test and Defect Verification are ready and have published in wiki https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Full+Regression+Test+Guidance https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Defect+Verification+Guidance On Fri, May 3, 2013 at 4:05 PM, Shenfeng Liu liush...@gmail.com wrote: Hi, all, I just want to update on our next plan for AOO 4.0 Testing. Since sidebar FVT already finished, we are currently preparing for a full regression which will cover the following areas: (1) Basic Function Verification (2) MS Interoperability Test (3) 2nd phase of sidebar testing (4) Defect verification So following works are on going: - Yi Xuan and Yu Zhen are inputting test cases in Testlink. - Yu Zhen and I are working on are test guidance for the Full Regression Test, and plan to publish it on our planning wiki for reference. - Then we wait for the next snapshot build from Juergen which contains the most recent fixes. I saw many people joined and volunteered for QA work. I will keep a list and contact you all when the Regression Testing is kicked off. Thanks very much for your supporting to AOO QA work! - Shenfeng (Simon) -- MzK God, grant me the serenity
Re: Writing script for compilation AOO on GNU/Linux
2013/5/17 Albino B Neto bino...@gmail.com: I am writing a script [1] for compilation AOO on GNU/Linux. 1 - https://github.com/binoanb/scripts/blob/master/compilar_aoo4.sh I accepted feedbacks. :-) -- Albino B Neto albinopcs.wordpress.com twitter.com/binoanb www.debian.org Chave GPG: 5ED34354 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Critique of the Help/About box
On Fri, May 17, 2013 at 06:03:25PM +0200, Jürgen Schmidt wrote: 1. default version if vendor is Apache Software Foundation http://people.apache.org/~jsc/screenshots/About_default.png 2. if the vendor is somebody else http://people.apache.org/~jsc/screenshots/About_vendor.png Looks like you are configuring with something like --with-build-version=$(date +%Y-%m-%d %H:%M:%S (%a, %d %b %Y)) May be this can be set as default when the switch is missing in configure, so that the bots and the Dev.Snaps. have all the time stamp as BUILD_VER_STRING (and maybe add $OS-$CPUNAME). Regards -- Ariel Constenla-Haile La Plata, Argentina pgpRbJ7f7fjJ7.pgp Description: PGP signature
Re: Handlers Drawing - Desing of the nodes.
Hi Alan, -- ALG (iPad) Am 17.05.2013 um 19:42 schrieb Alan Eduardo Puc Pech alan.pucp...@gmail.com: Hi Armin Thanks for your help. You are welcome :) We need people for Draw/Impress and there is a lot to know before being able to do something, ready to help. Well, I am away next week, but okay. Ok about your question, I want to start bringing improvements in drawing, but I need to learn more of your code. You may have a look at the wiki stuff, also I usually write more or less background information in the bugtracker in fixed tasks, so maybe grep bugtracher for my fixes (which are often fixes in Drawinglayer and related stuff). Grep for ALG and also for AW (before marriage) therefore In drawing, I want to start by changing small things for example nodes. all for the purpose of experimentation and learning the code in drawing. and also add support lines of node to node, because I noticed he has not. Good startimg point, experiment! When you have a building version, all is open for this. BTW: Some interactive modes have line connections, e.g. in point edit mode when the control vectors for curves are visualized. Its all there and usable :-) Regards Alan. 2013/5/16 Armin Le Grand armin.le.gr...@me.com Alan, one more thing: - there are already massive changes on the way in this area in aw080 branch (branches/alg/aw080) which will collide later - maybe for partial buils the page http://wiki.openoffice.org/** wiki/Documentation/Building_**Guide_AOO#Partial_Buildshttp://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#Partial_Buildsis helpful Sincerely, ArminOn 16.05.2013 17:09, Armin Le Grand wrote: Hi Alan, On 16.05.2013 03:03, Alan Eduardo Puc Pech wrote: Hi all. I need your help, I would like to change the design of the nodes. Because now in drawing, the nodes are square and have color cyan. Therefore I would like to know what code manipulates the node shapes square in color cyan. These handles are defined in png bitmaps in main\default_images\svx\res\* *markers.png, markers2.png (for 2nd marker mode) and markersACC.png (for high contrast) and are expected there at the given pixel positions. You can.. - change these with a graphic editor (caution, they have alpha (!)) - build the svx module to build the svx ressources - copy these (from main\solver\400\wntmsci12\** workdir\ResTarget\svxen-US.**res) to your office installation (search there) - repack the image ressources in main\packimages, deliver from there - copy main\packimages\wntmsci12\bin\**images.zip to your installation Alternatively, rebuild the office and install the new installation set... It is okay to play around with these and changing them in your local copy. Changing them in trunk will need discussion on this list, of course. svdmrkv.cxx is the correct starting point to see how selection handling is prepared principally; it's old code, partially cleanedup and adapted to primitive usage and overlay mechanism. It is not easy to understand and not very modular (well, more than some years ago, at least :-)). If you need assistance, I am raedy to help. Maybe you start with explaining what you want to do and why...? HTH! Sincerely, Armin Now I have this code: http://opengrok.adfinis-**sygroup.org/source/xref/aoo-** trunk/main/svx/source/svdraw/**svdmrkv.cxxhttp://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/svx/source/svdraw/svdmrkv.cxx This code is in the following line: /SRC_ROOT/main/svx/source/**svdraw/svdmrkv.cxx Regards Alan. -- ALG --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- ALG --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Problem with GSoC application
Hello everyone, I have a problem with my GSoC application. I thought that GSoC is only for 10 weeks. My applications has plans only for 10 weeks. In reality, GSoC is for 15 weeks. The deadline to change my application is over. Any solutions? -- Rajath S, M.Sc(Hons.) Physics, Birla Institute of Technology and Science - Pilani, Pilani
Re: [buildbot] investigate nightly windows build
On 5/17/2013 1:53 AM, Oliver-Rainer Wittmann wrote: Hi, On 17.05.2013 01:53, Andrew Rist wrote: our buildbot building trunk nightly for windows has problems in modul apr since a couple of days. Unfortunately, the log does provide nothing for a reason not known to me. Thus, I will try to investigate the problem. Hopefully, I can change the buildbot script to get the build output directly on stdout instead of as html. The html output is currently not containing the corresponding information about the build of module apr. Done and Thx to Herbert triggering a clean build. Unfortunately, the build was successful. Thus, I assume the reason that we had no nightly windows builds from trunk since 2013-04-28 was that no clean build had been performed. This is not the case. The clean build is not the panacea you see it as. As mentioned in several other communications, I went onto the box and cleaned up some processes that were hung (win7, win7snap, and win7ia2). All built successfully - even though the other two were incremental. The hung processes tend to occur /more/ during clean builds - not all the time, just more often. Thus, clean builds are more likely to create this type of build failure, they are not a fix as you're suggesting. Thanks for the information. In order to have something more tangible for fixing this defect of hanging build processes I propose to start an corresponding investigation. At least we should have a look after each build, esp. after each clean build, if there are processes which hang. It seems that this defect just occured with build #105 of aoo-w7ia2 - see [1]. The build had been killed. I assume that the one or the other process of this build is still working. Can somebody with corresponding karma check, if there are again hanging processes? [1] http://ci.apache.org/builders/aoo-w7ia2/builds/105 The build was not killed - the process that was running didn't report back in 12000 sec = 200 min or 3+hours At that point the buildbot tries to clean up, but this is the reaction, not the root cause. command timed out: 12000 seconds without output, killing pid 2472 SIGKILL failed to kill process using fake rc=-1 program finished with exit code -1 That is what I meant by killed - sorry for not expressing myself clear. When I checked it later, the process was still hung (thus it's unlikely that our problem is just with the length of the timeout). This is what one of these hung processes looks like, and any subsequent builds will fail if it's not cleaned up, as the processes lock files and block subsequent compiles of the same package. Thanks for having a look. Build #106 of aoo-w7ia2 went well after your clean up. Unfortunately, build #107 of aoo-w7ia2 had again the same failure as build #105. ok - so I am now killing the hung processes - here is what I find: * cl.exe - cl /nologo /? * sh.exe - C:\cygwin\bin\sh.exe -c dmake -P2 verbose=true /cygdrive/.../apr.txt 21 * perl.exe - C:\cygwin\bin\perl.exe E:/.../build.pl --all --html -P2 -- -P2 when I kill the cl process the other two come to life - i.e. that's the hung process looking in to the html progress page, the build is now finishing without reporting errors. A. Best regards, Oliver. Best regards, Oliver. Andrew, can only you perform such an investigation, because (as far as I know) you are the only who have direct access on the machine? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
unexpected results with Linux Intel RPM install, developer snapshot
I installed the Linux RPM pack the was I normally do -- 32 bit version -- but I'm not getting the normal directory structure for the /program directory -- only a bunch of library files. So, no runnable program. Can someone else try this and see if the results are the same for them. Maybe I really messed up...I will try installing again. -- MzK God, grant me the serenity to accept the things I cannot change, The courage to change the things I can, And wisdom to know the difference. -- The Serenity Prayer, adapted from Reinhold Niebuhr
ERROR: error 65280 occurred while making home/user/aoo/main/svx/prj
Hello, I have the following error when I build AOO: http://ooo.pastebin.ca/2377453 I'm building on Ubuntu. What could be the solution? What causes this error? Help me Regards
Re: Need QA (test) volunteers on Mac
I will work on my build this weekend because I am interesting in doing QA and development on the Mac. On Fri, May 17, 2013 at 9:22 AM, Rob Weir robw...@apache.org wrote: It looks like the QA team is making great progress with testing Apache OpenOffice 4.0 on Windows. But they need more help on Mac. Another few volunteers would make a big difference here. We're looking for people who can spend a few hours over the next week or two to run specific, pre-defined test cases their Mac, and to enter Bugzilla issues for any failed test cases. This is a nice, gentle introduction to formal QA. No previous experience with QA is necessary, though good familiarity with OpenOffice from a user perspective is recommended. If you can help, please send a note to the QA mailing list at: q...@openoffice.apache.org Thanks! -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
