Re: [HELP NEEDED] old Solaris related build issues
On 4/4/2016 2:59 PM, Marcus wrote: Am 04/04/2016 11:30 PM, schrieb Kay Schenk: ... In any case, since we don't currently have "official" distros for Solaris -- I would be content changing all these issues to ENHANCEMENT rather than DEFECT. Thoughts? I think this wouldn't change the actual problem: Somebody has to do the change in the code. We have neglected this platform and this is IMHO also one reason that we don't offer any builds anymore. Let's see what Patricia will say about the effort she sees. ... I think Apostolos Syropoulos makes a strong case for using gcc in preference to SunStudio. A lot depends on whether the changes suggested in the article https://asyropoulos.wordpress.com/2014/02/05/compiling-openoffice4/ still work. It was last modified in 2014. I can't determine that very easily without experimenting. If the rest of the PMC wants me to make the effort, I would request a Solaris ssh account from Adfinis, check out the current trunk there, check/apply all available Solaris patches, including the switch to gcc, and attempt a build. If the patches work, and pass inspection, I would commit them to svn. If that all works, I could continue to review, test, and check in patches suggested by people working on Solaris. Would I need AOO BugZilla issues supporting my changes? Patricia - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [HELP NEEDED] old Solaris related build issues
Am 04/04/2016 11:30 PM, schrieb Kay Schenk: On 04/04/2016 08:00 AM, Marcus wrote: Am 04/04/2016 12:11 PM, schrieb Απόστολος Συρόπουλος: yes, that's nice. But you shouldn't commit fixes without a possibility to test if it was good. Would you? ;-) First I did this in the past. Please see https://asyropoulos.wordpress.com/2014/02/05/compiling-openoffice4/ interesting. Thanks for the link. At that time I was sure the patches would find their way to source tree, but apparently they have been ignored... Nobody has said we don't do it and they are not more open-minded. I said that they are more open-minded! And I based this on my own personal experience. Not to mention that since you got the code from a company that produces Solaris, out of courtesy you should ensure the suite compiles under Solaris... We made the opposite experience. So, sorry that I've a different opinion. It's simply a fact that we have no experts for Solaris and no testing hardware. Hardware? We are not talking about SPARC machines. Nobody I didn't know that it's not about SPARC. This changes indeed the problem a bit. ;-) More in my answer to Patricia's mail. Marcus In any case, since we don't currently have "official" distros for Solaris -- I would be content changing all these issues to ENHANCEMENT rather than DEFECT. Thoughts? I think this wouldn't change the actual problem: Somebody has to do the change in the code. We have neglected this platform and this is IMHO also one reason that we don't offer any builds anymore. Let's see what Patricia will say about the effort she sees. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [HELP NEEDED] old Solaris related build issues
On 04/04/2016 08:00 AM, Marcus wrote: > Am 04/04/2016 12:11 PM, schrieb Απόστολος Συρόπουλος: >>> >>> yes, that's nice. But you shouldn't commit fixes without >>> a possibility >>> to test if it was good. Would you? ;-) >>> >> >> First I did this in the past. Please see >> >> https://asyropoulos.wordpress.com/2014/02/05/compiling-openoffice4/ >> > > interesting. Thanks for the link. > >> At that time I was sure the patches would find their way >> to source tree, >> but apparently they have been ignored... >> >>> Nobody has said we don't do it and they are not more >>> open-minded. >> >> I said that they are more open-minded! And I based this on >> my own >> personal experience. Not to mention that since you got the >> code >> from a company that produces Solaris, out of courtesy you >> should >> ensure the suite compiles under Solaris... > > We made the opposite experience. So, sorry that I've a > different opinion. > >>> It's simply a fact that we have no experts for Solaris >>> and no testing >>> hardware. >> >> Hardware? We are not talking about SPARC machines. Nobody > > I didn't know that it's not about SPARC. This changes indeed > the problem a bit. ;-) > > More in my answer to Patricia's mail. > > Marcus In any case, since we don't currently have "official" distros for Solaris -- I would be content changing all these issues to ENHANCEMENT rather than DEFECT. Thoughts? -- MzK "Time spent with cats is never wasted." -- Sigmund Freud - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [HELP NEEDED] old Solaris related build issues
Am 04/04/2016 12:11 PM, schrieb Απόστολος Συρόπουλος: yes, that's nice. But you shouldn't commit fixes without a possibility to test if it was good. Would you? ;-) First I did this in the past. Please see https://asyropoulos.wordpress.com/2014/02/05/compiling-openoffice4/ interesting. Thanks for the link. At that time I was sure the patches would find their way to source tree, but apparently they have been ignored... Nobody has said we don't do it and they are not more open-minded. I said that they are more open-minded! And I based this on my own personal experience. Not to mention that since you got the code from a company that produces Solaris, out of courtesy you should ensure the suite compiles under Solaris... We made the opposite experience. So, sorry that I've a different opinion. It's simply a fact that we have no experts for Solaris and no testing hardware. Hardware? We are not talking about SPARC machines. Nobody I didn't know that it's not about SPARC. This changes indeed the problem a bit. ;-) More in my answer to Patricia's mail. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [HELP NEEDED] old Solaris related build issues
Hi Marcus, * :) On Thu, 2016-03-31 at 00:41 +0200, Marcus wrote: [...] > @Nicolas: > AFAIK your company (Adfinis SyGroup AG) is managing the ports for > Solaris Sparc and x86. Is it possbile to get help from you for this case? Thanks for keeping me in the loop! Unfortunately we do not have enough resources to have a look at this in a reasonable time frame. We spent a huge amount of time trying to get 4.x working on Solaris, but after fighting with many different issues we gave up at some point (compilation went through roughly 1/3 of the code base). We still habe the boxes ready, up and running - if someone would like to have a look at it, feel free to contact us on a...@adfinis-sygroup.ch an we'll gladly provide you with an SSH account so you can get your hand dirty ;) Have a nice day! Kind regards, Nicolas -- Adfinis SyGroup AG Nicolas Christener, Bereichsleiter Services, GPG KeyID: 557DD2D6 Keltenstrasse 98 | CH-3018 Bern Tel. +41 31 550 31 11 | Direkt +41 31 550 31 13 signature.asc Description: This is a digitally signed message part
Re: [HELP NEEDED] old Solaris related build issues
On 4/4/2016 2:28 AM, Marcus wrote: ... It's simply a fact that we have no experts for Solaris and no testing hardware. ... Solaris runs on Intel PC hardware, so no need for special testing hardware. From the late 1980's to 2002, I was a system performance analyst and architect for servers that ran Solaris, while working for FPS Computing, Cray Research Superservers, and Sun Microsystems. During that time, I used it as the operating system on the workstation in my office. I was involved in helping the Solaris developers make the changes to get it to run well on 64 processor servers. I have used kadb to look at Solaris internals, while debugging hardware. I last used Solaris well over ten years ago, and don't know whether I would qualify as an "expert" for this purpose, but I could probably remember enough to be able to help a bit. There is a real resource limit. I have a finite amount of time to spend on AOO, and any time I spend on Solaris will be time I don't spend on other subprojects. Patricia - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: procedure for going from RC to release
On 04/03/2016 06:17 PM, Marcus wrote: Am 04/03/2016 09:42 PM, schrieb Andrea Pescetti: Carl Marcum wrote: I was looking at how some other projects handled "extras" things like this. Other projects designed their trees in a different way. I found Maven uses sub-folders under release/maven for plugins, plugin-tools, etc, that don't go into their main release folder. [1]. Well, here the issue is: we have assumed so far that the OpenOffice project releases, well, OpenOffice. This will still be true, but about one user in ten millions will want the NetBeans plugin. We can't make things more complex for the other 99,9% of users due to this. So for example, one thing we can't do is to partition (now) our "openoffice" tree into "releases" (for the "real" releases) and "devtools". If we had known this years ago, it would have made sense even with the large difference in numbers. In other words: I would consider https://dist.apache.org/repos/dist/release/openoffice to be taken. There will be no "releases" subfolder created in it, to avoid large management costs for something 99,9% of users won't use. Either we go for the dirty solution you advocate, where we mix release numbers and the "devtools" folder (which I don't like, but this is also not worth a long discussion honestly), or you place the plugin sources in some existing place. Should we use something like a devtools subfolder under release/openoffice so they don't have to be redone for each maintenance release of AOO or end up with multiples in each AOO release? Multiple? You will want to look up the distinction between dist and archive. If you don't find the relevant documentation, just ask and I'll dig it up from the website. https://dist.apache.org/repos/dist/release/openoffice/devtools/ I don't know how going for the "dirty" solution will affect scripts. It will surely result in misaligned trees in dist/ and SourceForge but this is not particularly problematic. If I recall correctly the download page options are populated via JS, but in turn that JS is probably generated (by Marcus?) based on some tree inspection; so this would need a check too, to ensure the extra "devtools" directory doesn't get in the way. On the other hand, the extra "devtools" folder will be ugly, but it will provide a container for all releases that are not related to our "main" product. We could at least agree that http://www.openoffice.org/download/ won't change at all with the plugin release, right? of course. As you wrote correctly 99% of our users will not use the plugin. And the remaining 1% are no users but devs. And these people will use it directly from Netbeans anyway. ;-) So, I would see releasing the plugin as a part of the open source promise: Everybody can have a look into the source code to see what is going on - if they like to do it. Sure, I can implement also this pckage into the JS download scriping and provide something on the download page. However, I really doubt that it is worth the effort. ;-) OK seriously, Carl: - You can do whatever you see fit to release the source package regarding filenames, directory structure or where to put it in the tree on SourceForge. It will not influence the other AOO download behavior. Adding it in the "source/" dir along with the other files is OK. Or create a new "devtools/" dir. - When you have some documentation ready or just in mind, don't forget to mention this source package incl. a link. Then we can proof that it is available as open source. - As far as I've understood, the important part is the binary at Netbeans.org, right? Then we should keep the effort on openoffice.org as low as possible as it is just for 1%. - And, finally, when we see that something was done wrong. OK, then let's fix it at the lastest with the next plugin release. My 2 ct. Marcus Hi Marcus, Yes all these are source only. The binaries for the netbeans integration will be from netbeans.org and the bootstrap-connector and groovy UNO are Maven repo. Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [HELP NEEDED] old Solaris related build issues
> > yes, that's nice. But you shouldn't commit fixes without a possibility > to test if it was good. Would you? ;-) > First I did this in the past. Please see https://asyropoulos.wordpress.com/2014/02/05/compiling-openoffice4/ At that time I was sure the patches would find their way to source tree, but apparently they have been ignored... > > Nobody has said we don't do it and they are not more open-minded. > I said that they are more open-minded! And I based this on my own personal experience. Not to mention that since you got the code from a company that produces Solaris, out of courtesy you should ensure the suite compiles under Solaris... > It's simply a fact that we have no experts for Solaris and no testing > hardware. > Hardware? We are not talking about SPARC machines. Nobody cares about these machines anymore. We are talking about "ordinary" computers with Intel or Intel-like processors. Second you do not need experts. You only need people that know Unix. After all, we are not takling about driver porting here... > If we would have it, then we would build and test the code. Or if > someone else is taking this over. So, maybe you want to help us? We are > open for this. :-) > I am sure the whole OpenIndiana community would like to help provided you do a few simple things: abandon SunStudio for Solaris and change the MAKE files according to our suggestions. A.S. -- Apostolos Syropoulos Xanthi, Greece
Re: [HELP NEEDED] old Solaris related build issues
Am 04/04/2016 11:14 AM, schrieb Απόστολος Συρόπουλος: one problem of integrating patches is that you need to test them if the trunk builds are still OK or if some adjustments are necessary. However, AFAIK no developer has a Solaris machine under the desk and therefore it's not a good idea to commit fixes when you don't know what the results are. ;-) Look the people of LibreOffice have abandoned SunStudio and have included such patches in their source tree and now LibreOffice compiles just fine. In fact, OpenIndiana has a LibreOffice package. yes, that's nice. But you shouldn't commit fixes without a possibility to test if it was good. Would you? ;-) That's also the reason why the build environment still uses Sun Studio and nothing else - instead or additional. When I tried to compile with SunStudio I realized that the building tools require a really ancient version of the compiler that has no provision for language constructs, etc., that are included in the code. For example, the template library is ancient and does not include things that the source code expects. So practically it is next to impossible to compile OpenOffice with SunStudio. Since you are not going to change your mind, better remove all Solaris bits so the make the code cleaner. Fortunately, the LibreOffice people are more open-minded... Nobody has said we don't do it and they are not more open-minded. It's simply a fact that we have no experts for Solaris and no testing hardware. If we would have it, then we would build and test the code. Or if someone else is taking this over. So, maybe you want to help us? We are open for this. :-) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [HELP NEEDED] old Solaris related build issues
> > one problem of integrating patches is that you need to test them if the > trunk builds are still OK or if some adjustments are necessary. However, > AFAIK no developer has a Solaris machine under the desk and therefore > it's not a good idea to commit fixes when you don't know what the > results are. ;-) > Look the people of LibreOffice have abandoned SunStudio and have included such patches in their source tree and now LibreOffice compiles just fine. In fact, OpenIndiana has a LibreOffice package. > That's also the reason why the build environment still uses Sun Studio > and nothing else - instead or additional. When I tried to compile with SunStudio I realized that the building tools require a really ancient version of the compiler that has no provision for language constructs, etc., that are included in the code. For example, the template library is ancient and does not include things that the source code expects. So practically it is next to impossible to compile OpenOffice with SunStudio. Since you are not going to change your mind, better remove all Solaris bits so the make the code cleaner. Fortunately, the LibreOffice people are more open-minded... A.S. -- Apostolos Syropoulos Xanthi, Greece
