Release 4.2 discussion addendum -- we're using /trunk
I can't believe I forgot probably the most important point here. We will be using everything we've got in /trunk unless there's some HUGE compelling issue not to. -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Fwd: Re: Questions about buildbot internals
FYI: communication with pono from infra Forwarded Message Subject:Re: Questions about buildbot internals Date: Tue, 23 Aug 2016 09:31:45 -0700 From: Kay sch...@apache.org Reply-To: ksch...@apache.org To: Pono Takamori CC: infrastruct...@apache.org Infrastructure , kay.sch...@gmail.com On 08/23/2016 08:52 AM, Pono Takamori wrote: > Q1: Are you talking about during a job or as a one time action? I can > get lists of currently installed packages on the linux nodes fairly > easily, the windows one will be a bit trickier unless you want to know > specific versions of your dependencies. I'd be happy with a one time action currently. Yeah, Windows is tricky. > > Q2: We can add those 2 jars to the build nodes. maven 2 should be > installed on those boxes, did you need a specific version of it? OK, I think whatever is out there now is fine for Maven. So, just installing these jars is /usr/share/java should do the trick. and, hmmm...we recommend ant 1.9 or later yet it seems what's on the Linux32 buildbot is ant 1.8.2 and on Linux-64 it's ant 1.7.1. Time to re-edit our configure.ac -- again. So, if you could bump the ant version to 1.9.2 on all these that would be great. More than 1.9.2 we have problems from my recollection. > > In regards to puppet, all three of the build nodes that you mentioned > are not in puppet since tethys is running Ubuntu 10.04, bb-vm2 is > running 12.04 and we do not have any puppet written for windows yet. OK, I actually didn't notice that these Linux bots were on different Ubuntu versions--gee! > We could move the builds to a node with 14.04 so that adding > dependencies would be you forking the listed repo and then adding the > required dependencies > here: > https://github.com/apache/infrastructure-puppet/blob/deployment/data/ubuntu/1404.yaml#L316 hmmm...let me confer with others and I'll get back to you on this. Can you get me a pack list for 14.04 as well? > > Let me know if you have any other questions, > -Pono Not right now. Thank you SO much for helping with this. Let's keep in touch! > > On Mon, Aug 22, 2016 at 9:32 PM, Kay sch...@apache.org > <mailto:sch...@apache.org> <mailto:ksch...@apache.org>> wrote: > > Hello Infra-- > Apache OpenOffice uses the following buildbots: > Linux32 : bb-vm2_ubuntu_32bit > Linux64: tethys_ubuntu > Windows 7: bb-win7 > > Q1: Short of writing a command line entry into our buildbot > scripts, is > there any way to get a listing of what packs are installed on > these systems? > > Q2: We need the following packs installed on all three of these for > automated testing: > junit-4.12.jar > hamcrest-core-1.3.jar > > Maybe maven2 also? But I just ran the tests I needed with "ant" > which is > part of our build requirements. > > Through private message, I was sent a link to: > > https://github.com/apache/infrastructure-puppet/tree/deployment/modules/build_slaves > > <https://github.com/apache/infrastructure-puppet/tree/deployment/modules/build_slaves> > > as a way of explanation to self-servicing the buildbots, but, not > being > a puppet guru, I am lost looking at this. Can you describe a basic > procedure for me? What type of karma does anyone need? And to what? > What's required to upload a new template? Instructions on what > should be > in the template. How do we initiate pull requests based on the > templates, etc? > > Thanks. > > > -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[DISCUSS] Release 4.2: General Topics
Hello all-- I think it would be valuable to discuss some general issues/ideas with the upcoming 4.2 release. My plan is to keep this general discussion "in play" until Sat, Sept 3, then do a summary with what was agreed to. WARNING: This is quite long! *PRIORITIES* 1. Update the localization. We've had quite a bit of work by the localization folks since the 4.1.1 release. This was the last release, in 2014-08-21 to import localization updates. Currently, it seems we might also add 3 new languages: Uyghur, Sinhala, and Icelandic with the 4.2 release. This would include both UI translations and Help translations. We need volunteers to lead this endeavor. I, personally, don't know anything about this process. This is a very high priority and it would be good to port translations over to our main repository as soon as possible for testing. 2. Update Java requirement from Java 1.5 to *at least* Java 1.7 I am rather adamant that we change our building requirement to Java 1.7 for all platforms. I will be changing that in our Building Guide today. Java 1.5 went out of support by Oracle in November, 2009. We use OpenJDK but I'm sure updates for Java 1.5 through that channel are also no longer available. Even Java 1.7 has reached end of life by Oracle for public support as of April, 2015. To avoid undue issues for some of our current users on older platforms, I am "OK" with java 1.7. I am fairly confident ALL users can obtain this for whatever platform they are using. 3. Issues for inclusion We need to include submitted/tested patches since 4.0.x. This should not include UI changes which would need to undergo a much longer test period. The ones I've identified are: https://bz.apache.org/ooo/buglist.cgi?bug_status=CONFIRMED&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=RESOLVED&f1=product&f2=component&f3=attachments.ispatch&f4=attachments.description&o1=notsubstring&o2=notsubstring&o4=substring&order=Importance&query_format=advanced&resolution=---&v1=ui&v2=ui&v4=patch&version=4.0.0&version=4.0.0-dev&version=4.0.1&version=4.0.1-dev&version=4.1.0&version=4.1.0-beta&version=4.1.0-dev&version=4.1.1&version=4.1.2&version=4.1.2-dev&version=4.2.0-dev Due to the fact that I actually have trouble identifying patches in BZ, this query may not be inclusive, so please feel free to do your own investigation. Additionally, issue 127068, involving analytics on our source code would surely be worth investigating. https://bz.apache.org/ooo/show_bug.cgi?id=127068 You might also see commits involving code that are related to other issues that are not on the above query. *BUILDBOTS AND CONFIGURATION* 1. Move to different buildbots? I will be forwarding a communication I had this morning from infrastructure concerning our current issues with our buildbots and a possible solution. You will see that the Linux32 and Linux64 buildbots are not even the same version of Ubuntu. We could move to Ubuntu 14 for both these Linux buildbots where we would also have more control over what's installed on them. We need a volunteer to lead this effort. 2. Configuration Issues Add, at least the ant version we're checking for in our configuration is not the version recommended in our Building Guide. *PRODUCTION ENVIRONMENT* For all our past distributions, we've had our own production environment if you will. This means the end user binaries were produced on AOO developer equipment, and these developers took responsibility for signing the binaries and getting them uploaded to SourceForge. It has been suggested that we use the ASF buildbots to produce our binaries with this release. My feeling is that unless we can "move" to a new buildbot environment that is more consistent with our two Linux distributions, we can'd to this. The issues with using an AOO production environment vs ASF is this: * it is much easier to script signing of binaries and move them to SourceForge on AOO supplied production equipment. * if we use ASF buildbot output, the binaries need to be downloaded to some other location by developers for signing, computing checksums, etc. There is no direct shell access to the buildbot machine that I am aware of for transfer purposes. Andrea has volunteered to set up a production environment for us. SEE: http://markmail.org/message/b4dbjdeu4llczqwt We need PMC members to volunteer with this effort if we decide to continue with the AOO production environment. --- the end for now -- This is probably enough for now. More coming over the next few days. -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Release Manager for 4.2.0?
On 08/19/2016 08:20 PM, Keith N. McKenna wrote: > >>> >> >> Hi all-- >> >> I am volunteering to be release manager for 4.2.0. I have been involved >> in all the AOO releases since 3.40, and I'm familiar with the process. >> Like all of us involved with the project, I am a volunteer. Due to this, >> I can not provide an expected release date. Releases, as we know are >> community efforts. We'll release when we feel 4.2.0 is ready. >> >> So, I will let this offer stand the weekend just in case someone else >> feels they'd LOVE to do this. If we don't have any objections to my >> being the next release manager over the next 72 hours, we can get >> started next week ironing out what needs to be done. We will need LOTS >> of help! >> >> > Kay that is great for volunteering. I also will help wherever I can. > > Keith > > Thanks to all who responded for your support. I'm looking forward to this new adventure! -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ready to setup release build machines?
On 08/19/2016 10:37 AM, Dennis E. Hamilton wrote: > > >> -Original Message- >> From: Kay Schenk [mailto:kay.sch...@gmail.com] >> Sent: Friday, August 19, 2016 09:09 >> To: dev@openoffice.apache.org >> Subject: Re: Ready to setup release build machines? >> >> >> >> On 08/12/2016 12:22 PM, Dennis E. Hamilton wrote: >>> I thought that the basic requirement is that the release manager(s) do >> any builds on a machine under their [exclusive] individual control. >> That also means satisfying baseline requirements for release builds >> though. That pretty much requires use of a VM if the main development >> system of a release manager is aligned with different tools and >> dependencies. >> >> I don't find any requirement like this vis a vis building by the release >> manager per se. The release is voted on by the community. So, in a >> sense, building/testing is the responsibility of all who vote on a >> release. >> >> See: www.apache.org/dev/release-publishing.html > [orcmid] > > That page is rather obsolete. For example, we have two branches on > dist.apache.org, one of which is for dev (and where we put release > candidates) and the other is release where we move any approved candidates. > The dist ... release contents are automatically mirrored to > archive.apache.org which seems to be the proper place to refer to these > (although there is mirroring to consider, but not for 4.1.2-patch1). > > The release page does not address binaries. I saw the business about where > official binaries are to be built somewhere and must find it. The Release Publishing page does address binaries: http://www.apache.org/dev/release-publishing.html It also discusses the importance of "distribution" of ASF releases on ASF servers but doesn't say anything about how that distribution, either source or binaries, is created with respect equipment ownership, etc. Publishing Releases is linked from the Release Policy page: http://www.apache.org/dev/release > > Since we put binaries through a form of this process (usually concurrently) > there does need to be some sort of provenance on those binaries. > > >> >>> >>> I am not so certain about putting up shared release-build VMs on non- >> ASF infrastructure though. >> >> Our "official", "required" release artifact is the source code for a >> release. >> >>> >>> One advantage to using ASF infrastructure is to bring code signing >> into the fold. That seems rather important down the road. >> >> We have been signing ALL release artifacts -- including all the binaries >> -- since AOO 3.4. So code signing of everything we release is already >> part of this process. > [orcmid] > > The use of PGP signatures on our release artifacts is a different matter than > code signing that is recognized by the operating system and is part of the > installer, not a detached signature that users must check manually. The > signatures I meant are *embedded* in the artifacts, including .msi, .dll, and > .exe files. > > I was thinking of this form of signed installs. That is a big deal for > Windows, where the OS will check them automatically, and they are also > reported in the Properties for the signed artifact. It also applies to all > of the DLLs and such that are loaded with the install. I believe that Andrea > has the private key that was issued for that but we have not managed to use > it to sign the code. This is usually done as part of building distributable > binaries. > > That private key is precious and is not to be shared. Ideally, it would > belong to root@ but I don't think we have a process for that. > > >> >> We require a production environment accessible by the release manager >> and helpers because producing distribution binaries in another location >> (seperate developer machine), signing and then uploading ALL the >> binaries to SourceForce by individuals is a horrendous undertaking. >> Ariel Constenla-Haile provided binaries for the 3.4 release and I'm sure >> he can attest to this. If we can set up a production environment under >> ASF infrastructure, of course this would be ideal. But, I see no reason >> why this environment couldn't have shell access by AOO developers who >> are likely to do code signing. >> >> > [ ... ] > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Ready to setup release build machines?
On 08/21/2016 10:46 AM, Andrea Pescetti wrote: > On 19/08/2016 Dennis E. Hamilton wrote: >> I thought that the basic requirement is that the release manager(s) do >> any builds on a machine under their [exclusive] individual control. > > This way one would need to rely on individual volunteers to coordinate > for a release. It is not impossible, of course. All our Apache > OpenOffice releases have used this model so far. But a shared > environment allows for knowledge sharing. And a developer can always > clone the shared VM locally for total control on his builds (assuming > trust between the PMC members having access). Or he can rebuild his > environment from scratch, but always with a "reference" VM that he can > inspect. Well, this would depend on who wanted access I guess -- I mean given your original proposal. You didn't' specify how login credentials would be maintained. > > Anyway I'm not going to start the effort unless someone says that this > could be useful for Windows builds too. We REALLY REALLY NEED the CentOS5 32-bit and 64-bit VMS regardless of what we do for Windows. Conceptually, we COULD use the Win7 buildbot to spin out the binaries for each language, but, then there's that download them ALL and do the signing on some other box I was talking about earlier. I think we need this "production farm" soon! It would be great to set it up and just run it weekly under cron with ALL langs as soon as possible. What do you need from us to get this going? Were you planning on doing the CentOS5 installations and then get back to us? Do you need a commitment for the WindowsVM? > >> I believe that Andrea has the private key that was issued for that but >> we have not managed to use it to sign the code. > > It was time-limited and it expired. I'm not sure what Infra decided to > do (they were examining options for code signing, with no big preference > for the solution in use; this was about 6 months ago). OK, we need to touch bases with them. And, find a committer that knows how to do this. > >> That private key is precious and is not to be shared. > > The understanding in this case is that it shouldn't be on shared > infrastructure. But the other benefits of shared environments still hold. > > Regards, > Andrea. Thanks so much for this update! > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Download Junit and Hamcrest in ./bootstrap?
On 08/18/2016 02:00 PM, Kay Schenk wrote: > > > On 08/17/2016 04:37 PM, Don Lewis wrote: >> On 12 Aug, Damjan Jovanovic wrote: >>> Sadly it's not that simple: Junit builds with Maven, and Hamcrest with >>> Gradle. >>> >>> Is it ok to download the binaries, or is only source code allowed under >>> ext_sources? >> >> I think it would be misleading because of the directory name. Dragging >> in extra dependencies just to build the .jar files seems like a waste. >> Downloading everything to one directory would make life easier, so it is >> too bad about the name. >> >> The description for OOO Extras on Sourceforge says this: >> >> A space to store classic OOo dependencies that cannot be easily >> redistributed in Apache OpenOffice's SVN tree, >> >> Initially this was meant for copyleft tarballs only but it is also >> pretty handy to mirror other file dependencies. >> >> Since ext_sources isn't distributed in the source archives for >> releases, checking even non-copyleft source tarballs into svn under that >> directory only helps people who are building from sources checkout out >> via svn. > > Do we know if the current buildbots have ANY version of Junit or > Hamcrest installed? As near as I could determine, our "last" published > version requirement for Junit was junit-4.10: > > https://wiki.openoffice.org/wiki/QA/test_automation_guide#Prerequisites_2 > > > Or, it might be better to request direct access to the buildbots for > this kind of installation. > > > We can request installation of packs on the buildbot but they need to be in the form of deb packages. I found hamcrest here: https://mirror.hmc.edu/ubuntu/pool/main/libh/ and junit4 here: https://mirror.hmc.edu/ubuntu/pool/main/j/junit4/ from Ubuntu repos. @Damjan: can you provide a combination that would work? -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Release Manager for 4.2.0?
On 01/28/2016 04:06 PM, Andrea Pescetti wrote: > As I wrote a few day ago, in theory it would be good to release > OpenOffice 4.2.0 in February. If it happens a bit later it wouldn't be a > big issue, but I believe that, in the constant balance between periods > where we are focused on talks (internal to OpenOffice and with the > enlarged community) and periods where we are more focused on the > OpenOffice product, it's time to start working again towards a release. > > For 4.2.0 we need a Release Manager. I would prefer NOT to be the > Release Manager for 4.2.0 since I'm finding that in this period I can > help more productively with tasks that do not require constant > interaction than with tasks that require a constant monitoring of > project channels. > > I am surely available to have a significant role in the 4.2.0 release, > especially with getting localization working again (actually, this mail > also serves as announcement that I am going to ask for higher privileges > on the Pootle server in order to check the translation workflow); but if > someone else steps in as a Release Manager we could deliver earlier. > > So if anyone is interested feel free to discuss this on list, or to > contact me off-list if you prefer, or to discuss in person at FOSDEM > next weekend! > > Regards, > Andrea. > Hi all-- I am volunteering to be release manager for 4.2.0. I have been involved in all the AOO releases since 3.40, and I'm familiar with the process. Like all of us involved with the project, I am a volunteer. Due to this, I can not provide an expected release date. Releases, as we know are community efforts. We'll release when we feel 4.2.0 is ready. So, I will let this offer stand the weekend just in case someone else feels they'd LOVE to do this. If we don't have any objections to my being the next release manager over the next 72 hours, we can get started next week ironing out what needs to be done. We will need LOTS of help! -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PATCH DOWNLOAD] Draft for the hotfix webpage
On 08/13/2016 02:16 PM, Marcus wrote: > As we have now the patched library file and Readme for all platforms, > IMHO not much more is needed to go public with the hotfix. Therefore > I've created a draft version of the hotfix download webpage: > > http://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/hotfix.html > > Please review and tell me your feedback. > > Thanks > > Marcus Looks good to me. -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
On 08/11/2016 12:50 PM, Kay sch...@apache.org wrote: > > > On 08/09/2016 02:12 PM, Kay Schenk wrote: >> [top posting] >> I'm in the process of trying to "sync" instructions for Linux32, >> Linux64, and MacOSX at the moment. As far as instructions on the actual >> HOTFIX page, we need to have just a "general" instruction for ALL zips >> that simply says -- "Unzip this package to some folder of your choosing >> and read the README that's included." Everything else should be in the >> various READMEs for each platform. >> >> I should be done with all edits by this evening for a final review >> before zipping and signing. > > Ok, I've now moved on to creating zip files, etc for Linux32, Linux64 > and Mac. > > My openssl version on does NOT supply digest sha256. Is it OK to use > sha1? MD5 already computed for each of these. sha1 is referenced on the ASF code signing page so I decided it was OK. :) So I think I'm done with the Linux32, Linux64, and MacOSX zip artifacts. Please check at: https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ If anything's amiss, it's likely I can't get back to this until Sunday. Or feel free to fix. > >> >> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote: >>> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING]. >>> >>>> -Original Message- >>>> From: Marcus [mailto:marcus.m...@wtnet.de] >>>> Sent: Thursday, August 4, 2016 15:52 >>>> To: dev@openoffice.apache.org >>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows >>>> >>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk: >>> [ ... ] >>>>> >>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet. >>>>> >>>>> Should we get started on these? >>>> >>>> it depends what we want that they should contain. The ZIP file for >>>> Windows contains a LICENSE and NOTICE file as well as an ASC file for >>>> the DLL. As it is only a patch IMHO we don't need to provide another >>>> LICENSE and NOTICE file which is already available in the OpenOffice >>>> installation. Also the ASC is not necessary as we provide it already >>>> (together with MD5 and SHA256) for the whole ZIP file. >>> [orcmid] >>> >>> I think there is a misunderstanding. Two matters: >>> >>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF practice >>> is to include NOTICE as well on binary distributions. The patch qualifies, >>> especially when it is moved to general distribution. It is also easy and >>> harmless to provide. >>> >>> 2. The reason for preserving the .asc on the shared-library binary is >>> because it authenticates with respect to who produced it and establishes >>> that it has not been modified as supplied in the package (or as the result >>> of some glitch in creation of the Zip). It provides a level of >>> accountability and, also, auditability. >>> >>> Even though few people will check all of these, they remain possible to be >>> checked. Since this is a matter of security vulnerabilities and involves >>> elevation of privilege to perform, I believe it is important to demonstrate >>> diligence and care, so that users have confidence in this procedure to the >>> extent they are comfortable. Also, if it becomes necessary to troubleshoot >>> a problem with these patch applications, we have the means to authenticate >>> what they are using to ensure there are no counterfeits being offered to >>> users. >>>> >>>> That means that only the README and library file remains. >>>> >>>> When the README for Windows keep its length then I don't want to copy >>>> this on the dowload webpage. ;-) >>>> >>>> So, when we put the README for all platforms in their ZIP files then we >>>> can just put a pointer to it on the download webpage and thats it. >>> [orcmid] >>> >>> Yes, that seems like a fine idea. The README can be linked the same way >>> the .md5, .sha256, and .asc are linked. >>> >>> Also, the README may become simpler if we can link to some of the >>> information and not have so much detail in the README text itself. It >>> might even be useful to have an .html README for that matter. But that is >>> all extra. Right now I think we
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
On 08/09/2016 02:12 PM, Kay Schenk wrote: > [top posting] > I'm in the process of trying to "sync" instructions for Linux32, > Linux64, and MacOSX at the moment. As far as instructions on the actual > HOTFIX page, we need to have just a "general" instruction for ALL zips > that simply says -- "Unzip this package to some folder of your choosing > and read the README that's included." Everything else should be in the > various READMEs for each platform. > > I should be done with all edits by this evening for a final review > before zipping and signing. Ok, I've now moved on to creating zip files, etc for Linux32, Linux64 and Mac. My openssl version on does NOT supply digest sha256. Is it OK to use sha1? MD5 already computed for each of these. > > On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote: >> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING]. >> >>> -Original Message- >>> From: Marcus [mailto:marcus.m...@wtnet.de] >>> Sent: Thursday, August 4, 2016 15:52 >>> To: dev@openoffice.apache.org >>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows >>> >>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk: >> [ ... ] hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet. Should we get started on these? >>> >>> it depends what we want that they should contain. The ZIP file for >>> Windows contains a LICENSE and NOTICE file as well as an ASC file for >>> the DLL. As it is only a patch IMHO we don't need to provide another >>> LICENSE and NOTICE file which is already available in the OpenOffice >>> installation. Also the ASC is not necessary as we provide it already >>> (together with MD5 and SHA256) for the whole ZIP file. >> [orcmid] >> >> I think there is a misunderstanding. Two matters: >> >> 1. The use of LICENSE is required by the ALv2 itself, and the ASF practice >> is to include NOTICE as well on binary distributions. The patch qualifies, >> especially when it is moved to general distribution. It is also easy and >> harmless to provide. >> >> 2. The reason for preserving the .asc on the shared-library binary is >> because it authenticates with respect to who produced it and establishes >> that it has not been modified as supplied in the package (or as the result >> of some glitch in creation of the Zip). It provides a level of >> accountability and, also, auditability. >> >> Even though few people will check all of these, they remain possible to be >> checked. Since this is a matter of security vulnerabilities and involves >> elevation of privilege to perform, I believe it is important to demonstrate >> diligence and care, so that users have confidence in this procedure to the >> extent they are comfortable. Also, if it becomes necessary to troubleshoot >> a problem with these patch applications, we have the means to authenticate >> what they are using to ensure there are no counterfeits being offered to >> users. >>> >>> That means that only the README and library file remains. >>> >>> When the README for Windows keep its length then I don't want to copy >>> this on the dowload webpage. ;-) >>> >>> So, when we put the README for all platforms in their ZIP files then we >>> can just put a pointer to it on the download webpage and thats it. >> [orcmid] >> >> Yes, that seems like a fine idea. The README can be linked the same way the >> .md5, .sha256, and .asc are linked. >> >> Also, the README may become simpler if we can link to some of the >> information and not have so much detail in the README text itself. It might >> even be useful to have an .html README for that matter. But that is all >> extra. Right now I think we want to get into the testing and see how to >> smooth what we have. >> >> PS: A friend of mine is looking into the MacOSX situation. He points out >> that one can use the Finder to do the job without users having to use >> Terminal sessions. I don't have further information at this time. >> >> PPS: The inclusion of scripts that do the job is also worthy of >> consideration, perhaps making it unnecessary to build executables. I will >> be looking at finding a .bat file that works safely for the Windows case. >> That can make the instructions much shorter :). >> >>> >>> To cut a long story short: >>> I would say yes for a ZIP file for every platform. >> [ ... ] >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Download Junit and Hamcrest in ./bootstrap?
On 08/11/2016 01:42 AM, Damjan Jovanovic wrote: > Hi > > If you've been checking the buildbots you'll see that all who don't use > --without-junit are currently broken in ./configure due to junit being too > old. This is unlikely to change, as the buildslaves are running Ubuntu > 10.04 which doesn't have newer versions of Junit available in apt. > > This is part of a bigger problem, which is that Junit's dependencies > changed multiple times in the 4.x releases, which is why I changed > configure.ac to need at least 4.11 (the maximum being 4.12). > > Instead of needing a correct system Junit version to run tests during the > build, and having to worry about having correct system versions of Hamcrest > on the classpath, should we not rather treat them like external > dependencies and download specific versions during ./bootstrap? It's under > 300 kB for both, and the bvt/fvt/pvt tests already download their own copy. > > Damjan > This would be OK with me. What version of the jre does Junit 4.11 require? I can't find information about this on the junit site --http://junit.org/junit4/ Right now, we're still spec'd at jdk 1.6 for everything except Windows, but IMO we should advance to 1.7 . -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: expat upgrade patch needs testing
On 08/09/2016 10:34 AM, Andrea Pescetti wrote: > Don Lewis wrote: If you get through the build, that's a pretty good test. During the build saxparser uses expat to read the .xml files for all of the locales. The other thing that expat seems to get used for is the tree view of help topics. Help -> OpenOffice Help -> Contents > > Just built on Linux 64. Both OK for me, with the current trunk > (including the recently merged gbuild). > >> I don't have upload access, but I suggest that you just try again. > > Kay, me and a bunch of other people have access to ooo-extras and can > give you upload access (for now or for the future). We just need your > SourceForge username. > > Regards, > Andrea. Hi Andrea -- I already have access. I just tried bootstrap again and all is good. I'm not sure why the URL1 for this failed. I can upload to ooo-extras when I get a moment, or someone else can. OK, back to building. :) -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Resurrecting the subsequent tests
On 08/09/2016 09:21 AM, Damjan Jovanovic wrote:
> Hi
>
> Now that the buildbots work, and we are planning to start with releases
> again, it would be nice to have a good set of tests to run against
> releases, and running them against nightly builds wouldn't hurt either.
>
> Our unit tests do run during the build and pass, but they cover very
> little. Sady, even the subsequent tests ("OOO_SUBSEQUENT_TESTS=1 build" in
> a module) fail badly.
>
> Firstly all recent JUnit versions need Hamcrest at run-time, or they throw
> ClassNotFoundException. As of r1755627 which I committed a few minutes ago,
> this can be specified in --with-hamcrest-core, and trying "./configure
> --with-junit" without it will fail. The versions you'll need are JUnit >=
> 4.11 and Hamcrest = 1.3. It's currently fixed in gbuild modules only.
Thanks for this info.
>
> Next we have the widely used but missing
> org.openoffice.test.OfficeConnection class, which was mysteriously deleted
> by liuzhe in r1378870:
>D /incubator/ooo/trunk/main/test/source
> possibly by accident as the commit message is "Updates for Enabling Daily
> Testing". This was in test.jar which is still a widely listed dependency.
> It is not easy to undelete that directory as "main/test/" was later moved
> to just "test/" and repurposed for QA tests. Should we rather resurrect the
> old main/test/source in another module, possibly qadevOOo?
>From what I see, qadevOOo seems like a reasonable place if we can get
that to work.
>
> The paths to the OpenOffice instance to test are also outdated, but that's
> easy to fix.
>
> Damjan
Again, thank you for investigating all this. We DO need to resurrect
testing!
--
Kay Schenk
Apache OpenOffice
"Things work out best for those who make
the best of the way things work out."
-- John Wooden
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Planning for emergency releases
On 08/08/2016 09:26 PM, Patricia Shanahan wrote: > On 8/8/2016 11:14 AM, Marcus wrote: >> Am 08/08/2016 07:28 PM, schrieb Andrea Pescetti: >>> On 07/08/2016 Marcus wrote: Maybe we are not that far aways from each other. What I want to to avoid is to provide hundreads of MBs for a single fix. Of course we can do a 4.1.3 with some collected fixes. As I don't know what is coming in the future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when the calendar is still showing 2016. ;-) >>> >>> The right trade-off would be between two and three releases a year >>> (including maintenance releases). >>> >>> Based on history, we've never been -and we are not- in a "release now >>> since there is a known critical exploit circulating", so the "emergency >>> release" is not likely to happen often. >>> >>> It will be enough to be in a permanent "ready to release" mode (where >>> work is still mostly on the infrastructure side, the rest is OK) and use >>> this readiness to ship emergency releases in the unlikely case we need >>> one, and a few maintenance/feature releases from time to time. >> >> it seems we have the same wish with regard to releases. We can just hope >> that this can come true. >> > > +1 on "ready to release" mode. However, rather than just hoping it can > come true, I would like to work on a plan to make it come true. > Some ideas about steps: * an "ongoing" or permanent release manager. * a quick turnarond on issues inclusion. Currently, we take quite a while with this. This would be at a minimum. It is not impossible and really not all that difficult to spin off JUST the rpms or deb packages to deal with specific issues for Linux. This would be an enhancement to just distributing files as with our current patches. The same probably can not be said of Windows or Mac, however. -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Any chance to merge the gbuild branch rather soonish?
On 07/30/2016 09:51 PM, Damjan Jovanovic wrote: > The problem is definitely in r1409590, in the LinkTarget.mk patch. > > On Fri, Jul 29, 2016 at 2:12 AM, Damjan Jovanovic wrote: > >> I've narrowed this Windows build performance regression down to the >> original branches/gbuild commits 1409589 and 1409590, which go together and >> can't be split up. >> >> * r1409589: gnumake4: #i117845#: LinkTarget.mk: fix dep-files for >> GenCxxObjects: >> pass the dep-file target explicitly as a parameter to the >> Object__commands. >> * r1409590: gnumake4: #i117845#: LinkTarget.mk: refactor dep-files: >> introduce dependency from object dep-file to object. >> >> The make rules involved are complex and affect all platforms. Proceeding >> further is a real PITA :-(. >> So sorry. :( Thanks again for all your hard effort! >> >> >> On Fri, Jul 22, 2016 at 7:05 PM, Damjan Jovanovic >> wrote: >> >>> The Windows build performance regression first occurs in r1735004, which >>> takes 676 minutes to build compared to 330 minutes in the commit just >>> before it. Only wall clock time increases, "user" and "system" times remain >>> the same. >>> >>> 4 patches from branches/gbuild were merged in that commit. 3 of them are >>> rather complex and none jump out at me, so I'll have to do more splitting >>> up and building to find the one responsible. >>> >>> >>> >>> >>> On Wed, Jul 20, 2016 at 9:53 AM, Damjan Jovanovic >>> wrote: >>> I am back to gbuild, have moved my Windows VM's disk to the faster ext3 filesystem, and have begun doing the only thing I can think of to debug this: manually "bisection testing" the gbuild-reintegration branch to try isolate which patch causes the build performance regression. There is 136 patches ported from the branches/gbuild branch that have been merged in batches to branches/gbuild-reintegration. Patch 129 builds in 341 minutes. Patch 43 builds in 335 minutes. So it must be one of the 42 most recent patches. Currently compiling patch 16. On Mon, May 23, 2016 at 11:26 PM, Kay Schenk wrote: > On 05/05/2016 10:51 AM, Damjan Jovanovic wrote: > >> Windows XP SP3 32-bit on a VirtualBox instance on FreeBSD, underlying >> filesystem is ZFS which does cause I/O slowdown, but not enough to >> explain >> this. >> >> Can't remember what compiler I installed; there are Windows SDK 7 and >> Visual Studio 9 directories. >> > > Despite the lag, I'd like to get back to this given all your effort so > far. > > Do you still have your config.log? It should show in there what it > found for the C compiler. > > OK, and maybe a crazy idea. Despite the fact that we're having problems > with the Win7 build for our usual processing, would it be worth doing a > merge INTO the guild branch and setting up an additional win buildbot for > that? > > >> SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0" >> ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH" >> --with-midl-path="$SDK_PATH/bin" >> --with-ant-home="/cygdrive/c/apache-ant-1.9.6" --with-dmake-url=" >> http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2"; >> --with-epm-url=" >> http://www.msweet.org/files/project2/epm-3.7-source.tar.gz"; >> --enable-pch --disable-atl --disable-activex --without-junit >> --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio >> 9.0/VC" >> --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" >> --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0" >> --disable-directx >> --with-package-format="installed" --enable-wiki-publisher >> >> I am currently thinking we will gain more from porting to Java, than >> trying >> to maintain a build system for the buggy, leaky, complex, crash-prone, >> insecure languages that are C/C++. >> > > I don't know if its C++, which is still very widely used for > programming development, or our complicated code, of which I'm guessing, > at > least 25% could be eliminated. > > > > >> On Thu, May 5, 2016 at 7:18 PM, Kay Schenk >> wrote: >> >> On Tue, May 3, 2016 at 12:07 PM, Damjan Jovanovic >>> wrote: >>> >>> Unfortunately I discovered a major problem with the gbuild-reintegration branch: on Windows, the build time of trunk is about 3-4 hours, but it's over 12 hours to build gbuild-reintegration :-(. I don't have time to investigate soon, nor do I know where to even begin... >>> Hi Damjan, and thanks for this update even it is disappointing. >>> >>> Could you share what the specifics are for the Windows platform you're >>> using for the build? >>> >>> * specific Windows OS >>> * C compiler and flags >>> * build options
Re: Officially releasing a patch for CVE-2016-1513
OK, I think I'm done with the LInux64 bit area as well. And see below On 07/31/2016 01:10 PM, Marcus wrote: > Am 07/31/2016 08:52 PM, schrieb Kay Schenk: >> Well...I didn't see this message before I got started and I just >> finished with Linux32 and used Ariel's patch for this. Of course it can >> be changed if desired. File size wise, Ariel's patch seemed more in >> keeping with what I have. You can see what I put on the commit for this. >> I don't want to get in the middle of whose patches to use, so someone >> else can re-commit and change this if they like. >> >> I need some review on the VERY large README I put out there for Linux32. >> I know some Linux folks are not comfortable with the command line, so, >> it turned out larger than I had originally anticipated. >> If the linux64 stuff is similar, I'll just basically do the same for it. >> I don't run on Linux64 so I can't do any comparisons between file sizes >> provided by Carl vs Ariel. > > I don't think that there won't be any differences when I look at your > instructions in the README. > >> And finally, I put out the MacOSX patch already but have NO instructions >> because I don't know Mac. Someone else will need to write and commit the MacOSX instructions. >> >> I won't be doing anything with the Windows area at all, leaving that to >> someone else. >> >> In summary, I will finish up doing the same for Linux64 today in a while. >> >> I won't have time to work on any more of this until Tuesday at the >> earliest. > > I'm preparing the hotfix webpage. For this I've some questions: > > 1. Do we want to provide zip files for every platform or just single > files for the library and other files? H... I assumed we would just be point people directly at /dist/release/openoffice/patches. (Right now, these are in /dist/dev/openoffice/patches.) It would be easiest to just setup the hotfix page with three links per distro. Linux32 * link to Linux32.README * link to linux32 libtl.so * link to linux32 libtl.so.asc (sig) etc. If not, the READMEs I wrote will need to change. Others may have a different opinion. > > 2. Can we add ASC, MD5, SHA256 files for every library (or zip) file? The developer sigs provided with the patches should be sufficient. maybe? Well this is why I was concerned about matching file sizes with what people already had. Hopefully, if some are a bit off, it won't be a deterrent for people to apply these. > > 3. Is this the final URL or just for our testing before moving to the > official URL? See above -- ? > > Thanks > > Marcus > > > >> On 07/31/2016 10:21 AM, Dennis E. Hamilton wrote: >>> I would prefer that we use Ariel's for the Mac and keep the other >>> Linux ones since those have been accounted for as having been put >>> through the confirmation process and smoke testing. I would like to >>> recognize as many of the contributors as possible. I used Carl's 64-bit patch. >>> >>> Kay, if you are going to do the uploads of the initial ones for the >>> dev/openoffice/4.1.2-patch1/binary/ area, let me know. I will not do >>> anything about added documentation for any of them until they are in >>> the SVN. >>> >>> If you do not, I will do so, with some initial documentation. >>> >>> - Dennis >>> -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Sunday, July 31, 2016 05:26 To: dev@openoffice.apache.org Subject: Re: Officially releasing a patch for CVE-2016-1513 On 30/07/2016 Kay Schenk wrote: > duplicate fixed > libraries for Linux-32, and Linux-64 based on submissions from Carl, > Damjan, and Ariel. I'd be happy to move these somewhere in the next day or > so, but I don't know what versions we want to use. Ariel's were built on a CentOS 5 system, so equivalent to the one we used for 4.1.2; I would thus tend to prefer those (while thanking all the others for providing builds!). > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 07/31/2016 05:55 AM, Carl Marcum wrote: > On 07/31/2016 08:25 AM, Andrea Pescetti wrote: >> On 30/07/2016 Kay Schenk wrote: >>> duplicate fixed >>> libraries for Linux-32, and Linux-64 based on submissions from Carl, >>> Damjan, and Ariel. I'd be happy to move these somewhere in the next >>> day or >>> so, but I don't know what versions we want to use. >> >> Ariel's were built on a CentOS 5 system, so equivalent to the one we >> used for 4.1.2; I would thus tend to prefer those (while thanking all >> the others for providing builds!). > > That's okay with me. > > Carl > >> >> Regards, >> Andrea. OK, thanks for the feedback. OK, I will use Ariel's patches and be moving the 2 Linux patches to: https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ in just a bit with some instructions for each -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
+1 this looks like a good plan On 07/24/2016 02:37 PM, Andrea Pescetti wrote: > While the severity of the security bug we disclosed > http://www.openoffice.org/security/cves/CVE-2016-1513.html is not > particularly high (it is classified as "Medium" with no known exploits > and anti-virus software can detect malicious documents), we should > release an update incorporating the -already tested- patch we disclosed > in the announcement. > > I assume we will want to keep the effort minimal. > > To do so, an outline would be: > > 1) We commit the patch to the AOO410 branch. This is the branch used for > all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our > reference version. > > 2) We do not make any other changes to the AOO410 branch. This is really > meant to be a minimal update. Even the version number in the source > package will remain 4.1.2. > > 3) We tag the release as AOO4121 and build the corresponding source > package, which will have 4.1.2.1 in its name (I mean the filename, > nowhere else). > > 4) We don't prepare full end-user release binaries but we do supply > repaired libraries for power users - remember the circumstances above. > The bugfix modifies one library file, and we have binaries ready for > several platforms already. > > 5) We vote on the source and possibly binaries. We advertise the > availability of the new packages on our website, but we don't send out > update notifications and we don't put the files on SourceForge. > > Does this look OK? > > Once this is done, we will probably want to open another discussion and > see how we can coordinate for a release that incorporates more fixes or > features and is made available in full form, with all localized > installers, to end users. But the above is mostly aimed in having an > official way to ship the existing patch. > > Regards, > Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
