Re: Problem with pootle
On 20/11/2014 13:01, Jürgen Schmidt wrote: On 19/11/14 18:16, Andrea Pescetti wrote: On 18/11/2014 Jürgen Schmidt wrote: I simply forgot it and have this step not on my list. Maybe we can add it on https://wiki.openoffice.org/wiki/Localization_for_developers to be aware of this step in the future. This page (which I will call A) has an outdated notice. It says that https://wiki.openoffice.org/wiki/Localization_AOO (B) is the updated version, and this one in turn says that https://wiki.openoffice.org/wiki/Localization_AOO/new_proposal (C) is better. Can we clarify this a bit? As things stand now (i.e., we use Pootle and don't have the genLang workflow enabled) which of A, B and C describes the current state of things and which one describes the latest ideas on genLang? I used mainly (A) and noticed the outdated as well :-( It's still on my to-do list to update the page according my notes and how I do it currently. This is of course independent of (C). I will also take a look on (B), I remember that this is an old page and we started to document our new collected knowledge on (A). Notices on pages A, B and C have been fixed accordingly. Still, it will be very good to have an update of A, especially the section about the SDF-Pootle conversion. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Reporting broken download link
The file downloads, but the resulting executable doesn't match the md5 signature given here: http://archive.apache.org/dist/openoffice/4.1.1/binaries/en-US/Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe.md5 The MD5 for this download does not pass the MD5 test (using MD5.exe used on Windows, see screenshot). MD5 from your website: 40fc525bc8b26ac7e1a7cef0e02a08f3 Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe Downloaded executable Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe is 140,852,175 bytes long *Browser variables* *Values* navigator.appCodeName Mozilla navigator.appName Netscape navigator.appVersion5.0 (Windows) navigator.platform Win32 navigator.oscpu Windows NT 6.1; WOW64 navigator.cpuClass undefined navigator.product Gecko navigator.productSub20100101 navigator.vendor navigator.vendorSub navigator.language en-US navigator.browserLanguage undefined navigator.userLanguage undefined navigator.systemLanguageundefined navigator.userAgent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 Debian / Ubuntu / IceWeasel ? No / No / No *Stable Release* *JavaScript functions/variables**Values* Language ISO code en-US Language ISO code (from select box) en-US Release matrix platform position (full) 11 Release matrix platform position (lp) 12 Release matrix platform array data y,134 Release matrix language array data en-US,English (US),English (US),y,download/index.html UI platform nameWindows (EXE) UI platform name (not supported) Platform (short)win32 URL platform name (full)Win_x86_install URL platform name (lp) Win_x86_langpack URL platform name (from select box) win32 Version (from select box) 4.1.1 File name (full)Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe File name (lp) Apache_OpenOffice_4.1.1_Win_x86_langpack_en-US.exe File extension .exe File size (full) (MByte)134 File size (lp) (MByte) 18 Release info Milestone AOO411m6 | Build ID 9775 | SVN r1617669 | Released 2014-08-21 Download file link (full) http://sourceforge.net/projects/openofficeorg.mirror/files/4.1.1/binaries/en-US/Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe/download Download file link (lp) http://sourceforge.net/projects/openofficeorg.mirror/files/4.1.1/binaries/en-US/Apache_OpenOffice_4.1.1_Win_x86_langpack_en-US.exe/download Checksum file link (full) (here for MD5) http://archive.apache.org/dist/openoffice/4.1.1/binaries/en-US/Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe.md5 Checksum file link (lp) (here for MD5) http://archive.apache.org/dist/openoffice/4.1.1/binaries/en-US/Apache_OpenOffice_4.1.1_Win_x86_langpack_en-US.exe.md5 Base URL to Sourceforge.net http://sourceforge.net/projects/openofficeorg.mirror/files/4.1.1/binaries/ Base URL to Apache Archive http://archive.apache.org/dist/openoffice/4.1.1 getLinkSelection() (download URL) undefined isLanguageSupported() (true/false) ?true Show the sub-box (true/false) ? true General error (true/false) ?false - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Digital signing release for windows.
On 26 December 2014 at 00:21, Andrea Pescetti pesce...@apache.org wrote: jan i wrote: It seems (as usual) that the discussion has died out, and nobody does anything (my apologies in advance I am wrong, I would very much like to be wrong). You are wrong (so it's good news!), but not so much. I started looking at it only 2 days ago and I didn't get far enough yet. I'm stuck in activating access due to a procedural issue being addressed by Infra; so I don't have the key, but only a preliminary password; and I haven't shared credentials with anyone else at the moment. Anyway, I concur this is a priority. I am pleased to be wrong, even though not so much, but some progress is a lot better than none. May I suggest that once you get access (no rush here, we need to prepare the release first), that you create 1-2 PMC credentials so that access is not lost if one credential gets locked. My suggestion is simple, lets rerun AOO 4.1 for windows, sign it digitally, and then release it as a patch version. As 4.1.1? As 4.1.2? From what machines? This is where the discussion is (not where it stopped). And it is a very concrete issue, not some theoretical stupidity. I'll state what I deem unacceptable (we can discuss it if you have different opinions, maybe your views on item C are different?): A) It is unacceptable that the next OpenOffice release is not signed B) It is unacceptable to call something 4.1.2 and release it on Windows only Since you talk as PMC there are no need to discuss further. But I have say AOO has a different way of using x.y.z than other projects. The x.y.2 signals a patch, and that is normally only done for the platforms who have the problem. If I follow your unacceptable then I hope we will never have a serious security issue on a single platform, since we would have to have to wait for a release on all platforms, that would in my opinion be unacceptable. I did on purpose not suggest 4.2 since that signals a full release on all platforms. C) It is unacceptable to call something 4.1.2 if it is 100% identical to 4.1.1 on Linux and Mac. Hmmm so if we have a security issue where we need to link against a new versions of e.g. openssl.lib then we cannot release itthat does not sound logical. Again if you release a patch for a limited set of platforms, it is because the source has not changed, but the surroundings (libraries, signing etc). D) It is unacceptable that the build is not the same quality as 4.1.1 (in terms of compatibility with Windows versions and so on); this risk is quite remote on Windows from what I see. +1 So I already wrote the two options, that can even coexist: 1) Put online new 4.1.1 Windows binaries This should really be a no-go. If we do that the checksums will change so people who have downloaded a legitimate 4.1.1 will suddenly see a non matching checksum. Doing this will be counterproductive to our marketing argument about always download from us, because its a trusted version. We cannot change checksums on something that is available on our mirrors Since you find platform patches unacceptable we could make a 4.1.1.1 but it would be kind of strange. 2) Create a 4.1.2 with minor updates and bugfixes, cherry-picking some trunk updates. If we choose that 4.1.2 will be a quick release, we may leave all translation updates out of it (Pootle is aligned to trunk at the moment). We cannot cherry-pick trunk updates, that would make it a 4.2 !!! Patches are meant to be critical fixes, and not random bug-fixes. I would favor option 2, provided we agree quickly (say, in one week) on what we get in it. You'll be happy to know that I have already shortlisted a few bugs that I see relevant for 4.1.2 (list available on request or in separate discussion). See above, to me that is full release 4.2 and not a patch to 4.1 I am happy to help, especially with the signing, but to help I need access to the certificate given to the PMC, and somebody who can make a release windows build. I can take care of the certificate part, which as I wrote move forward in the last couple of days. For sure, I can't help you with Windows builds. So you are saying you will need someone else, like Juergen? My vm for windows can build AOO, but due to some security work I do my windows libraries are far from standard, so I would not recommend using a binary from that vm for production. Steps are simple: 1) make a full build, pick all DLL, JAR and EXE from the object tree 2) Sign them, or let me help with that 3) Overwrite the object tree with the signed artifacts 4) run build but on postprocess (generate new setup package) 5) Sign the installer or let me help with that 6) Upload and start vote 7) Upload to dist and be happy. What is stopping us from doing something that simple ? This is OK for option 1 (the 4.1.1 replacement). Not quite for option 2, meaning that in that case you need the builds in all platforms. But
Re: Digital signing release for windows.
On 26/12/2014 jan i wrote: May I suggest that once you get access (no rush here, we need to prepare the release first), that you create 1-2 PMC credentials so that access is not lost if one credential gets locked. Definitely. I'm now being the contact person since we don't have appointed a release manager yet. In the end, for sure I will not be producing Windows builds and it makes sense that people who produce the builds have access to the system. B) It is unacceptable to call something 4.1.2 and release it on Windows only ... But I have say AOO has a different way of using x.y.z than other projects. The x.y.2 signals a patch, and that is normally only done for the platforms who have the problem. Historically we never released for one platform only. If we do it for 4.1.2 there will be people who erroneously believe we have dropped Mac or Linux; this is my concern more than the use of numbering. If I follow your unacceptable then I hope we will never have a serious security issue on a single platform, since we would have to have to wait for a release on all platforms, that would in my opinion be unacceptable. If the needs arises, I'm sure this can be discussed. But this is not the case now. And historically, again, indeed security updates were included in the normal release cycle. But as far as I know we were never in the position to have to get a release out within 24 hours due to security issues. So I would keep this discussion for when it happens. C) It is unacceptable to call something 4.1.2 if it is 100% identical to 4.1.1 on Linux and Mac. Hmmm so if we have a security issue... I'm speaking for 4.1.2, I'm not speaking in general. 1) Put online new 4.1.1 Windows binaries This should really be a no-go. If we do that the checksums will change Not necessarily, it all depends on how we restructure the web pages and the files tree on SourceForge. But nobody preferred this option across all discussions we had so far, so option 2 deserves more attention. 2) Create a 4.1.2 with minor updates and bugfixes, cherry-picking some trunk updates. ... We cannot cherry-pick trunk updates, that would make it a 4.2 !!! Patches are meant to be critical fixes, and not random bug-fixes. Probably we agree, we simply use different wording. For 4.1.2, the reference would be the 4.1.0 - 4.1.1 changes. See https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.1+Release+Notes and http://s.apache.org/AOO411-solved from there: we included bugfixes that did not have impact on UI, that did not introduce new features, that updated translations (this would be out in 4.1.2 as I explained) or dictionaries, or that allowed building/running more smoothly in certain environments. What they all had in common was to be low-risk and reviewed. Not all of them were really critical. I would do the same for 4.1.2, maybe fixing even just a handful of annoying bugs. I like option 2, but I am strongly against cherry picking updates on trunk. If we have serious bugs then they can be included. I do however not believe we have such bugs, otherwise we would have discussed 4.1.2 long time ago. I am open for option 2 as you describe it, if its called 4.2 All we need to agree upon is what we mean by serious. This is not hard. I think we can agree that 4.1.1 to 4.1.2 will be like 4.1.0 to 4.1.1, except that we put the threshold for inclusion higher, so we include fewer fixes (nowhere near the 89 fixes we had in 4.1.1). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Digital signing release for windows.
On 26 December 2014 at 13:11, Andrea Pescetti pesce...@apache.org wrote: On 26/12/2014 jan i wrote: May I suggest that once you get access (no rush here, we need to prepare the release first), that you create 1-2 PMC credentials so that access is not lost if one credential gets locked. Definitely. I'm now being the contact person since we don't have appointed a release manager yet. In the end, for sure I will not be producing Windows builds and it makes sense that people who produce the builds have access to the system. B) It is unacceptable to call something 4.1.2 and release it on Windows only ... But I have say AOO has a different way of using x.y.z than other projects. The x.y.2 signals a patch, and that is normally only done for the platforms who have the problem. Historically we never released for one platform only. If we do it for 4.1.2 there will be people who erroneously believe we have dropped Mac or Linux; this is my concern more than the use of numbering. And I agree that i a valid concern especially considering our current status. If I follow your unacceptable then I hope we will never have a serious security issue on a single platform, since we would have to have to wait for a release on all platforms, that would in my opinion be unacceptable. If the needs arises, I'm sure this can be discussed. But this is not the case now. And historically, again, indeed security updates were included in the normal release cycle. But as far as I know we were never in the position to have to get a release out within 24 hours due to security issues. So I would keep this discussion for when it happens. C) It is unacceptable to call something 4.1.2 if it is 100% identical to 4.1.1 on Linux and Mac. Hmmm so if we have a security issue... I'm speaking for 4.1.2, I'm not speaking in general. 1) Put online new 4.1.1 Windows binaries This should really be a no-go. If we do that the checksums will change Not necessarily, it all depends on how we restructure the web pages and the files tree on SourceForge. But nobody preferred this option across all discussions we had so far, so option 2 deserves more attention. ok. 2) Create a 4.1.2 with minor updates and bugfixes, cherry-picking some trunk updates. ... We cannot cherry-pick trunk updates, that would make it a 4.2 !!! Patches are meant to be critical fixes, and not random bug-fixes. Probably we agree, we simply use different wording. For 4.1.2, the reference would be the 4.1.0 - 4.1.1 changes. See https://cwiki.apache.org/confluence/display/OOOUSERS/ AOO+4.1.1+Release+Notes and http://s.apache.org/AOO411-solved from there: we included bugfixes that did not have impact on UI, that did not introduce new features, that updated translations (this would be out in 4.1.2 as I explained) or dictionaries, or that allowed building/running more smoothly in certain environments. What they all had in common was to be low-risk and reviewed. Not all of them were really critical. I would do the same for 4.1.2, maybe fixing even just a handful of annoying bugs. I have no real problem with your definition. I like option 2, but I am strongly against cherry picking updates on trunk. If we have serious bugs then they can be included. I do however not believe we have such bugs, otherwise we would have discussed 4.1.2 long time ago. I am open for option 2 as you describe it, if its called 4.2 All we need to agree upon is what we mean by serious. This is not hard. I think we can agree that 4.1.1 to 4.1.2 will be like 4.1.0 to 4.1.1, except that we put the threshold for inclusion higher, so we include fewer fixes (nowhere near the 89 fixes we had in 4.1.1). +1 lets get moving.I dont think we need a vote to make 4.1.2, we need a branch/tag in svn, include the bugs you have marked, a test build, and then we can vote on the source. Or close one eye, and make final signed release just in english, have the vote, and then make the other languages. rgds jan i. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Reporting broken download link
Am 12/26/2014 11:52 AM, schrieb Nigel Johnstone: The file downloads, but the resulting executable doesn't match the md5 signature given here: http://archive.apache.org/dist/openoffice/4.1.1/binaries/en-US/Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe.md5 The MD5 for this download does not pass the MD5 test (using MD5.exe used on Windows, see screenshot). MD5 from your website: 40fc525bc8b26ac7e1a7cef0e02a08f3 Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe Downloaded executable Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe is 140,852,175 bytes long I don't see a difference when downloading the executable and the MD5 hash from the URL you've mentioned above. For me it's identical. Please try again a download. Maybe there was an interuption. Or use the official download webpage for the current release: http://www.openoffice.org/download/ Or use another mirror sever of your choice: http://sourceforge.net/settings/mirror_choices?projectname=openofficeorg.mirrorfilename=4.1.1/binaries/en-US/Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe HTH Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: location of libraries/library/module/script DTDs?
| I'll dig up the specific filenames. 100016.odt 101028.odt 104556.odt 113481.odt 70065.odt 78691.odt 79664.odt 80654.odt 81045.odt 86470.odt These are examples of documents have the parcel-descriptor.xml file in the Scripts/ subdirectory of their package, which uses scripting.dtd. I got these files second-hand, from a dump of the AOO bug database, but I believe if you're good at the AOO bug database you could probably find them there. I can email a zip with one/more of these documents to anyone who wishes a copy. Sorry, my tools isn't done dumping out a nice summary of the info yet. :-) There are a LOT more files which use the script-lb.xml and script-lc.xml files, which appear to be tied to StarBasic, mostly in the Basic/* subdirectory of the package. A few of the above files have both (Java or JavaScript scripts and StarBasic, so have all 3 XML files and refer to all of the DTDs. Thanks, Lee - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Explaining Java (was RE: Java 32)
Am 12/25/2014 12:42 AM, schrieb Dennis E. Hamilton: I finished checking on the Java-specific messages and the six messages only have a single place where each is produced. It appears that a single (default en) page could provide the necessary information for reference from any messages in the installed binaries. Andrea suggests The page could be included in the set of standard pages (the xx pages, see http://openoffice.apache.org/website-native.html and then each translation team can decide whether to use the English one or their translated one. A. Is this a potential way to do it? 1. Create an ooo-site/trunk/content/xx/java/ directory. 2. Create leftnav.mdtext and index.mdtext files there. 3. The content/xx/java/index.mdtext would become the English Language version that We adopt for the target. If further breakout is required, it can be handled in that directory at a later time. B. Having done that, and having the message be agreeable, internationalization can commence. C. At an appropriate time, the content/java/ directory is created and it is arranged that this and content/xx/java/ are synchronized. (I have no idea what order this has to be in and which is the master.) D. The current content/download/common/java.html can be redirected to content/java/ Or E. The adjusted default messages that link to the site will link to http://openoffice.org/java and be in the build in time to test (4.1.2?) developer builds with the new messages and the new site pages. How am I doing? sounds good. To have this ready for a 4.1.2 sounds also be feasible. Marcus -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Monday, December 22, 2014 00:12 To: dev@openoffice.apache.org Subject: Re: Java 32 On 22/12/2014 Dennis E. Hamilton wrote: I am assuming that we can do the job with a single text. So I see no problem with where it is kept. One consideration might be the maintenance of the different-language versions and how browsers are routed to the correct one. The page could be included in the set of standard pages (the xx pages, see http://openoffice.apache.org/website-native.html and then each translation team can decide whether to use the English one or their translated one. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Explaining Java (was RE: Java 32)
On 25/12/2014 Dennis E. Hamilton wrote: A. Is this a potential way to do it? 1. Create an ooo-site/trunk/content/xx/java/ directory. 2. Create leftnav.mdtext and index.mdtext files there. 3. The content/xx/java/index.mdtext would become the English Language version that We adopt for the target. If further breakout is required, it can be handled in that directory at a later time. In xx we try to avoid too many subdirectories. The Java file could find a place in the product directory, and be referenced from the leftnav in that directory (extended a few hours ago). B. Having done that, and having the message be agreeable, internationalization can commence. C. At an appropriate time, the content/java/ directory is created and it is arranged that this and content/xx/java/ are synchronized. (I have no idea what order this has to be in and which is the master.) xx is generated from the English content, so steps are: write English page; copy to xx (structure, i.e., filenames and directories, may change); translators add it. D. The current content/download/common/java.html can be redirected to content/java/ Or E. The adjusted default messages that link to the site will link to http://openoffice.org/java and be in the build in time to test (4.1.2?) developer builds with the new messages and the new site pages. Correct. How am I doing? Well, except one detail: as I wrote earlier today, we cannot do it for 4.1.2 since strings in Pootle have already been updated and translators are already working on 4.2.0; so at the moment we have no way to add a string between 4.1.1 and 4.1.2 (also, 4.1.2 is not meant for string changes). I'm also curious about the new mechanism Jan described... well, very likely I'll know more about it at FOSDEM next month! Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Explaining Java (was RE: Java 32)
-- replying to this below -- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Friday, December 26, 2014 15:44 To: dev@openoffice.apache.org Subject: Re: Explaining Java (was RE: Java 32) On 25/12/2014 Dennis E. Hamilton wrote: A. Is this a potential way to do it? 1. Create an ooo-site/trunk/content/xx/java/ directory. 2. Create leftnav.mdtext and index.mdtext files there. 3. The content/xx/java/index.mdtext would become the English Language version that We adopt for the target. If further breakout is required, it can be handled in that directory at a later time. In xx we try to avoid too many subdirectories. The Java file could find a place in the product directory, and be referenced from the leftnav in that directory (extended a few hours ago). B. Having done that, and having the message be agreeable, internationalization can commence. C. At an appropriate time, the content/java/ directory is created and it is arranged that this and content/xx/java/ are synchronized. (I have no idea what order this has to be in and which is the master.) xx is generated from the English content, so steps are: write English page; copy to xx (structure, i.e., filenames and directories, may change); translators add it. orcmid How about this? Create an ooo-site/trunk/content/java/ *folder* where the index.htm will be the new version of the target file. This can be done in advance because and, after the text is considered OK, internationalization could proceed without pressure in anticipation of 4.2.0. there is no link to it from anywhere yet. The folder is both to allow the very short URL, http://openoffice.org/java in messages, and the possibility that there might be further more- technical detail in order to keep the main page straightforward. We'll know better in trying it out. /orcmid D. The current content/download/common/java.html can be redirected to content/java/ Or E. The adjusted default messages that link to the site will link to http://openoffice.org/java and be in the build in time to test (4.1.2?) developer builds with the new messages and the new site pages. Correct. How am I doing? Well, except one detail: as I wrote earlier today, we cannot do it for 4.1.2 since strings in Pootle have already been updated and translators are already working on 4.2.0; so at the moment we have no way to add a string between 4.1.1 and 4.1.2 (also, 4.1.2 is not meant for string changes). orcmid I missed the message about timing and 4.1.2 versus 4.2.0 somehow. So, we can we discuss changes to the messages and maybe make bugzilla issues but changes should not be made to the trunk until 4.1.2 is out the door? Whenever the messages are adjusted, they can refer to web pages that are already waiting, even if not linked from anywhere else up until then. It looks like the redirect from download/common/java.html could happen at any time it is considered that java/index.html is ready. /orcmid I'm also curious about the new mechanism Jan described... well, very likely I'll know more about it at FOSDEM next month! Regards, Andrea. - 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
