Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?
On Wed, Jul 25, 2018 at 6:30 PM Jim Jagielski wrote: > As readers no doubt recall, I'm been struggling with getting > the latest HEAD of 4.2.0 to build on macOS... The various > migrations of modules from the old build to gbuild, w/o > consideration for other platforms has broken things, both > related to required libs not being linked and/or copied > (fallout from the UDK versioning changes) as well as other > issues which I can't fathom. > > Is there anyone left who knows the build process well enough > that when I run into dead-ends could provide some clues > and helpful insights on at least where to look for possible > work-arounds and fixes? > > For example, jurt builds libjpipe.dylib and the build > process correctly links that to libjpipe.jnilib. However, > during later processing, it looks like that file isn't > copied over, and the build fails saying it cannot find > libjpipe.jnilib. If I forcibly link it, I can continue > the build, but then I get: > > Let's fix that jurt problem first. What does running "make showdeliverables" in the main/jurt directory give you?
Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?
On Wed, Jul 25, 2018 at 6:30 PM Jim Jagielski wrote: > As readers no doubt recall, I'm been struggling with getting > the latest HEAD of 4.2.0 to build on macOS... The various > migrations of modules from the old build to gbuild, w/o > consideration for other platforms has broken things, both > related to required libs not being linked and/or copied > (fallout from the UDK versioning changes) as well as other > issues which I can't fathom. > > Is there anyone left who knows the build process well enough > that when I run into dead-ends could provide some clues > and helpful insights on at least where to look for possible > work-arounds and fixes? > > For example, jurt builds libjpipe.dylib and the build > process correctly links that to libjpipe.jnilib. However, > during later processing, it looks like that file isn't > copied over, and the build fails saying it cannot find > libjpipe.jnilib. If I forcibly link it, I can continue > the build, but then I get: > Let's fix that jurt problem first. What does running "make showdeliverables" in the main/jurt directory give you?
VM Collection
Hi all, We had this Idea to collect VMs for all our supported systems. Is this still on? Can we have a MacOS VM too? I never got that setup on my Macbook Air. I am sure we manage to share a CentOS & Windows VM. All the best Peter - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A 4.1.6 Release
I do not believe we have a fix for that. so until someone fixes this, I do not see a chance. On 25.07.2018 17:18, FR web forum wrote: Regression: https://bz.apache.org/ooo/show_bug.cgi?id=127646 This release will fix it? - Mail original - De: "Jim Jagielski" À: "OOo Apache" Envoyé: Mercredi 25 Juillet 2018 15:48:00 Objet: Re: A 4.1.6 Release No worries. I have my VMs ready to go. On Jul 23, 2018, at 12:47 AM, Peter kovacs wrote: Fyi: To my frustration I failed yesterday to proceed. My next timeslot is on Wednesday. I hope nothing will interfere. Am 21. Juli 2018 08:28:47 MESZ schrieb Peter Kovacs : I hope i have time on Sunday. I wanted to proceed last Sunday but failed on this. Currently my calendar is kind of full. Next possible opportunity is conning Wednesday. I am undecided if the 4.1.6 will be the last release. But after 4.1.6 I agree 4.2.0 beta should get priority. I can imagine that at least one maintenance release could be possible while we stabilize 4.2.0. In the beta phase. Am 19. Juli 2018 19:49:46 MESZ schrieb Matthias Seidel : Back to the topic: If we want to release 4.1.6, we should start the process described here: https://cwiki.apache.org/confluence/display/OOOUSERS/How+to+Cook+a+Release That said, 4.1.6 should really be the last 4.1.x. (my opinion). We have to get 4.2.0 releasable! Regards, Matthias Am 04.07.2018 um 23:45 schrieb Marcus: Am 04.07.2018 um 22:46 schrieb Kay Schenk: On Wed, Jul 4, 2018 at 1:00 PM, Marcus wrote: Am 04.07.2018 um 08:23 schrieb Peter Kovacs: I think Jim is referring to the gstreamer situation, where we decided that we skip CentOS6 more or less for 4.2.0.And one argument was, if they want something they should support us. This is not showing sympathy for a small user group that uses very old software for 2 more years until they have to move to CentOS 7. I personally think that the gstreamer Topic can be solved after we have released a beta version. Damjan and I have pointed out a lot of possible ways to deal with the issue. Just for now I think we have other problems then gstreamer in 4.2.0. I think it is my fault that I put that argument so much in the front line, but that stuck for me. In the last months we had a drop in activity. And more then one topic received not the attention it deserved. I would not conclude that anyone has stopped caring at this point in time. Let us conclude for now: 4.1.x is still in maintenance. And in my opinion we could think of maintaining it until 2020 when CentOS6 drops out of maintenance. Some support from CentOS6 side would be nice. But we need to search someone for this. I have that on my todo list, but did not manage to follow it up. incl. gstreamer 0.1.0 that is now within the 4.1.x code. PS: CentOS 6 will be supported until Nov 2020; which means another ~2.5 years. 4.2.0 has I think 3 bugs we know about and that blocks a beta release. Current target for building with gstreamer is CentOS7. Building without gstreamer could be done on CentOS6. We should keep the code in trunc CentOS 6 compatible where ever we can for now. That will make it easy to back port patches to 4.1.x if we decide to maintain 4.1.x until EOL of CentOS6. In 4.2.0 we can still keep gstreamer 0.1.0 or update to something newer. To be honest, I don't care *about this special topic*. And it is only relevant on Linux, right? IMHO more relevant is the baseline: When we increase the CentOS version we also raise the sysreq for Linux kernel, glibc, etc. This has a much bigger impact for our users. You are absolutely correct about this, Marcus. Monitoring the 32-bit Linux downloads might help here. It does seem like AOO could be moving away from 32-bit for Linux and other operating systems. I don't know what impact this will have overall though. I don't remember exactly, does the gstreamer 0.1.0 vs. 1.0.0 discussion is also connected to the Linux 32-bit builds? If so, a solution could be indeed to drop the 32-bit builds. From SF.net stats I get the following (2018-01-01 until today). BTW: Very likely it's the used OS the download is started from. And not the OS where OpenOffice should be installed on. OS% --- Windows86,1165 Macintosh 7,8424 Unknown 4,9012 Linux 1,0621 Android 0,0762 BSD 0,0011 Solaris 0,0006 But even then, I'm sure the most downloads from resp. for Linux will be for 64-bit. Has anybody more exact numbers - or an idea how to get them? Marcus On 03.07.2018 23:50, Matthias Seidel wrote: What impact has Ant 1.10.x exactly on older machines? It is no problem for me to build the Windows version with Ant 1.9.12. As long as we use Java 8. But again, I just did a personal build to test AOO 4.1.x with Java 8. Nothing else. To be more precise: I was the only one who cared. No response from other members! Am 03.07.2018 um 23:19 schrieb Jim Jagielski: The above made it app
Re: A 4.1.6 Release
Yea, whish and reality are still on different parties... Do we have a template for the cwiki - release tracker? I tried to set the page up manually and it ended up in something that was not good. So I guess i did it wrong. thx Peter On 25.07.2018 15:48, Jim Jagielski wrote: No worries. I have my VMs ready to go. On Jul 23, 2018, at 12:47 AM, Peter kovacs wrote: Fyi: To my frustration I failed yesterday to proceed. My next timeslot is on Wednesday. I hope nothing will interfere. Am 21. Juli 2018 08:28:47 MESZ schrieb Peter Kovacs : I hope i have time on Sunday. I wanted to proceed last Sunday but failed on this. Currently my calendar is kind of full. Next possible opportunity is conning Wednesday. I am undecided if the 4.1.6 will be the last release. But after 4.1.6 I agree 4.2.0 beta should get priority. I can imagine that at least one maintenance release could be possible while we stabilize 4.2.0. In the beta phase. Am 19. Juli 2018 19:49:46 MESZ schrieb Matthias Seidel : Back to the topic: If we want to release 4.1.6, we should start the process described here: https://cwiki.apache.org/confluence/display/OOOUSERS/How+to+Cook+a+Release That said, 4.1.6 should really be the last 4.1.x. (my opinion). We have to get 4.2.0 releasable! Regards, Matthias Am 04.07.2018 um 23:45 schrieb Marcus: Am 04.07.2018 um 22:46 schrieb Kay Schenk: On Wed, Jul 4, 2018 at 1:00 PM, Marcus wrote: Am 04.07.2018 um 08:23 schrieb Peter Kovacs: I think Jim is referring to the gstreamer situation, where we decided that we skip CentOS6 more or less for 4.2.0.And one argument was, if they want something they should support us. This is not showing sympathy for a small user group that uses very old software for 2 more years until they have to move to CentOS 7. I personally think that the gstreamer Topic can be solved after we have released a beta version. Damjan and I have pointed out a lot of possible ways to deal with the issue. Just for now I think we have other problems then gstreamer in 4.2.0. I think it is my fault that I put that argument so much in the front line, but that stuck for me. In the last months we had a drop in activity. And more then one topic received not the attention it deserved. I would not conclude that anyone has stopped caring at this point in time. Let us conclude for now: 4.1.x is still in maintenance. And in my opinion we could think of maintaining it until 2020 when CentOS6 drops out of maintenance. Some support from CentOS6 side would be nice. But we need to search someone for this. I have that on my todo list, but did not manage to follow it up. incl. gstreamer 0.1.0 that is now within the 4.1.x code. PS: CentOS 6 will be supported until Nov 2020; which means another ~2.5 years. 4.2.0 has I think 3 bugs we know about and that blocks a beta release. Current target for building with gstreamer is CentOS7. Building without gstreamer could be done on CentOS6. We should keep the code in trunc CentOS 6 compatible where ever we can for now. That will make it easy to back port patches to 4.1.x if we decide to maintain 4.1.x until EOL of CentOS6. In 4.2.0 we can still keep gstreamer 0.1.0 or update to something newer. To be honest, I don't care *about this special topic*. And it is only relevant on Linux, right? IMHO more relevant is the baseline: When we increase the CentOS version we also raise the sysreq for Linux kernel, glibc, etc. This has a much bigger impact for our users. You are absolutely correct about this, Marcus. Monitoring the 32-bit Linux downloads might help here. It does seem like AOO could be moving away from 32-bit for Linux and other operating systems. I don't know what impact this will have overall though. I don't remember exactly, does the gstreamer 0.1.0 vs. 1.0.0 discussion is also connected to the Linux 32-bit builds? If so, a solution could be indeed to drop the 32-bit builds. From SF.net stats I get the following (2018-01-01 until today). BTW: Very likely it's the used OS the download is started from. And not the OS where OpenOffice should be installed on. OS% --- Windows86,1165 Macintosh 7,8424 Unknown 4,9012 Linux 1,0621 Android 0,0762 BSD 0,0011 Solaris 0,0006 But even then, I'm sure the most downloads from resp. for Linux will be for 64-bit. Has anybody more exact numbers - or an idea how to get them? Marcus On 03.07.2018 23:50, Matthias Seidel wrote: What impact has Ant 1.10.x exactly on older machines? It is no problem for me to build the Windows version with Ant 1.9.12. As long as we use Java 8. But again, I just did a personal build to test AOO 4.1.x with Java 8. Nothing else. To be more precise: I was the only one who cared. No response from other members! Am 03.07.2018 um 23:19 schrieb Jim Jagielski: The above made it appear that Ant 1.9.x was no longer supported plus had some sort of security rel
Re: Probleme im Calc
Please note that this mailing list is international and therefore for English only text. This makes sure that everybody has a chance to understand the mails. If you want to write in German then you can use its own mailing list: dev...@openoffice.apache.org More information about how to use mailing lists can be found here: https://openoffice.apache.org/mailing-lists.html HTH Marcus Am 25.07.2018 um 12:16 schrieb Rainer Schlegel: Hallo, eventuell bin ich hier richtig? [...] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Probleme im Calc
Hallo,
eventuell bin ich hier richtig?
ich nutze OO 4.1.3
Folgendes Problem:
ein Tabelle "Daten auslesen.ods" zählt in einer anderen Tabelle
(Statistik.csv) die Anzahl der belegten Zeilen und schreibt das Ergebnis in
eine eigene Zelle.
=ZÄHLENWENN('file:///S:/Statistik.csv'#$Tabelle1.D2:D30016;"<>").
Ergebnis ist z.Bsp. 5166 welches in Zelle sheet1.B41 von "Daten
auslesen.ods" geschrieben wird.
eine weitere Tabelle (auswertung.ods) fragt nun diese Zelle ab und schreibt
sie in eine eigene Zelle (Reiter 2018.b60)
='file:///S:/Daten auslesen.ods'#$Sheet1.B41
Ergebnis ist nun nicht 5166 sondern 5264 wo kommt die addition von
98 her?
und so geht es weiter:
"Daten auslesen.ods" sheet1.B42 steht 5649 in neuer Tabelle
9592; diff. 3943 ?
Ich lese doch nur die Zelle aus, wie kann so etwas vorkommen?
Bitte um eine Hilfe.
*Für Rückfragen stehe ich selbstverständlich zur Verfügung.*
*Vielen Dank im Voraus*
*Mit freundlichen Grüßen*
Rainer
--
Datenschutz ist kein Produkt. Datenschutz ist ein Prozess. _Übrigens:
Hinweise zu unserem Umgang mit personenbezogenen Daten finden Sie hier
Re: Help w/ AOO 4.2.0 build process - any knowledgable people left?
Hi instsetoo_native is the last module that is built, since it's the one responsible for generating installation packages. In your error the command "unopkg sync" fails. With our opengrok gone, I can't easily tell where register_extensions is. Also I wonder if unopkg sync is called correctly there, there's no filename. I am updating and rebuilding now to help you further. Damjan On Wed, Jul 25, 2018 at 5:49 PM Jim Jagielski wrote: > As readers no doubt recall, I'm been struggling with getting > the latest HEAD of 4.2.0 to build on macOS... The various > migrations of modules from the old build to gbuild, w/o > consideration for other platforms has broken things, both > related to required libs not being linked and/or copied > (fallout from the UDK versioning changes) as well as other > issues which I can't fathom. > > Is there anyone left who knows the build process well enough > that when I run into dead-ends could provide some clues > and helpful insights on at least where to look for possible > work-arounds and fixes? > > For example, jurt builds libjpipe.dylib and the build > process correctly links that to libjpipe.jnilib. However, > during later processing, it looks like that file isn't > copied over, and the build fails saying it cannot find > libjpipe.jnilib. If I forcibly link it, I can continue > the build, but then I get: > > ** > ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/ > unxmaccx.pro/Apache_OpenOffice/dmg/install/ca_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca/OpenOffice.app/Contents/program/unopkg > sync --verbose - env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed! > in function: register_extensions > ** > in function: register_extensionsstopping log at Tue Jul 24 17:29:46 2018 > .. removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/ > unxmaccx.pro/Apache_OpenOffice/dmg/stripped/bg ... > > I've no idea what that means and what could be causing that... > > So my question is whether there is anyone around who > has any ideas or clues on where to start...? Considering > that macOS is one of our largest downloads, it would be nice > to not have to drop it from AOO 4.2.0. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: A 4.1.6 Release
Regression: https://bz.apache.org/ooo/show_bug.cgi?id=127646 This release will fix it? - Mail original - > De: "Jim Jagielski" > À: "OOo Apache" > Envoyé: Mercredi 25 Juillet 2018 15:48:00 > Objet: Re: A 4.1.6 Release > > No worries. I have my VMs ready to go. > > > On Jul 23, 2018, at 12:47 AM, Peter kovacs > > wrote: > > > > Fyi: To my frustration I failed yesterday to proceed. My next > > timeslot is on Wednesday. I hope nothing will interfere. > > > > Am 21. Juli 2018 08:28:47 MESZ schrieb Peter Kovacs > > : > >> I hope i have time on Sunday. I wanted to proceed last Sunday but > >> failed on this. > >> Currently my calendar is kind of full. Next possible opportunity > >> is > >> conning Wednesday. > >> > >> I am undecided if the 4.1.6 will be the last release. But after > >> 4.1.6 I > >> agree 4.2.0 beta should get priority. I can imagine that at least > >> one > >> maintenance release could be possible while we stabilize 4.2.0. In > >> the > >> beta phase. > >> > >> > >> Am 19. Juli 2018 19:49:46 MESZ schrieb Matthias Seidel > >> : > >>> Back to the topic: > >>> > >>> If we want to release 4.1.6, we should start the process > >>> described > >>> here: > >>> https://cwiki.apache.org/confluence/display/OOOUSERS/How+to+Cook+a+Release > >>> > >>> That said, 4.1.6 should really be the last 4.1.x. (my opinion). > >>> We > >> have > >>> to get 4.2.0 releasable! > >>> > >>> Regards, > >>> > >>>Matthias > >>> > >>> > >>> Am 04.07.2018 um 23:45 schrieb Marcus: > Am 04.07.2018 um 22:46 schrieb Kay Schenk: > > On Wed, Jul 4, 2018 at 1:00 PM, Marcus > >> wrote: > > > >> Am 04.07.2018 um 08:23 schrieb Peter Kovacs: > >> > >>> I think Jim is referring to the gstreamer situation, where we > >>> decided > >>> that we skip CentOS6 more or less for 4.2.0.And one argument > >>> was, > >>> if they > >>> want something they should support us. This is not showing > >>> sympathy > >>> for a > >>> small user group that uses very old software for 2 more years > >>> until > >>> they > >>> have to move to CentOS 7. I personally think that the > >>> gstreamer > >>> Topic can > >>> be solved after we have released a beta version. Damjan and I > >> have > >>> pointed > >>> out a lot of possible ways to deal with the issue. Just for > >>> now I > >>> think we > >>> have other problems then gstreamer in 4.2.0. I think it is my > >>> fault > >>> that I > >>> put that argument so much in the front line, but that stuck > >>> for > >>> me. > >>> > >>> In the last months we had a drop in activity. And more then > >>> one > >>> topic > >>> received not the attention it deserved. I would not conclude > >>> that > >>> anyone > >>> has stopped caring at this point in time. > >>> > >>> > >>> Let us conclude for now: > >>> 4.1.x is still in maintenance. And in my opinion we could > >>> think > >> of > >>> maintaining it until 2020 when CentOS6 drops out of > >>> maintenance. > >>> Some > >>> support from CentOS6 side would be nice. But we need to > >>> search > >>> someone for > >>> this. > >>> I have that on my todo list, but did not manage to follow it > >>> up. > >>> > >> > >> incl. gstreamer 0.1.0 that is now within the 4.1.x code. > >> > >> PS: > >> CentOS 6 will be supported until Nov 2020; which means another > >> ~2.5 > >> years. > >> > >> 4.2.0 has I think 3 bugs we know about and that blocks a beta > >>> release. > >>> Current target for building with gstreamer is CentOS7. > >>> Building > >>> without > >>> gstreamer could be done on CentOS6. We should keep the code > >>> in > >>> trunc CentOS > >>> 6 compatible where ever we can for now. That will make it > >>> easy to > >>> back port > >>> patches to 4.1.x if we decide to maintain 4.1.x until EOL of > >>> CentOS6. > >>> > >> > >> In 4.2.0 we can still keep gstreamer 0.1.0 or update to > >> something > >> newer. > >> To be honest, I don't care *about this special topic*. > >> > >> And it is only relevant on Linux, right? > >> > >> IMHO more relevant is the baseline: When we increase the > >> CentOS > >> version we > >> also raise the sysreq for Linux kernel, glibc, etc. This has a > >> much > >> bigger > >> impact for our users. > > > > You are absolutely correct about this, Marcus. Monitoring the > >>> 32-bit > > Linux > > downloads might help here. It does seem like AOO could be > > moving > >>> away > > from > > 32-bit for Linux and other operating systems. I don't know what > > impact this > > will have overall though. > > I don't remember exactly, does the gstreamer 0.1.0 vs. 1.0.0 > discussion is also connected to the Linux 32-bit builds? If so, > a > solution
Help w/ AOO 4.2.0 build process - any knowledgable people left?
As readers no doubt recall, I'm been struggling with getting the latest HEAD of 4.2.0 to build on macOS... The various migrations of modules from the old build to gbuild, w/o consideration for other platforms has broken things, both related to required libs not being linked and/or copied (fallout from the UDK versioning changes) as well as other issues which I can't fathom. Is there anyone left who knows the build process well enough that when I run into dead-ends could provide some clues and helpful insights on at least where to look for possible work-arounds and fixes? For example, jurt builds libjpipe.dylib and the build process correctly links that to libjpipe.jnilib. However, during later processing, it looks like that file isn't copied over, and the build fails saying it cannot find libjpipe.jnilib. If I forcibly link it, I can continue the build, but then I get: ** ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/ca_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca/OpenOffice.app/Contents/program/unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed! in function: register_extensions ** in function: register_extensionsstopping log at Tue Jul 24 17:29:46 2018 ... removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/stripped/bg ... I've no idea what that means and what could be causing that... So my question is whether there is anyone around who has any ideas or clues on where to start...? Considering that macOS is one of our largest downloads, it would be nice to not have to drop it from AOO 4.2.0. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Help w/ AOO 4.2.0 build process - any knowledgable people left?
As readers no doubt recall, I'm been struggling with getting the latest HEAD of 4.2.0 to build on macOS... The various migrations of modules from the old build to gbuild, w/o consideration for other platforms has broken things, both related to required libs not being linked and/or copied (fallout from the UDK versioning changes) as well as other issues which I can't fathom. Is there anyone left who knows the build process well enough that when I run into dead-ends could provide some clues and helpful insights on at least where to look for possible work-arounds and fixes? For example, jurt builds libjpipe.dylib and the build process correctly links that to libjpipe.jnilib. However, during later processing, it looks like that file isn't copied over, and the build fails saying it cannot find libjpipe.jnilib. If I forcibly link it, I can continue the build, but then I get: ** ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/ca_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca/OpenOffice.app/Contents/program/unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed! in function: register_extensions ** in function: register_extensionsstopping log at Tue Jul 24 17:29:46 2018 ... removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/stripped/bg ... I've no idea what that means and what could be causing that... So my question is whether there is anyone around who has any ideas or clues on where to start...? Considering that macOS is one of our largest downloads, it would be nice to not have to drop it from AOO 4.2.0. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Help w/ AOO 4.2.0 build process - any knowledgable people left?
As readers no doubt recall, I'm been struggling with getting the latest HEAD of 4.2.0 to build on macOS... The various migrations of modules from the old build to gbuild, w/o consideration for other platforms has broken things, both related to required libs not being linked and/or copied (fallout from the UDK versioning changes) as well as other issues which I can't fathom. Is there anyone left who knows the build process well enough that when I run into dead-ends could provide some clues and helpful insights on at least where to look for possible work-arounds and fixes? For example, jurt builds libjpipe.dylib and the build process correctly links that to libjpipe.jnilib. However, during later processing, it looks like that file isn't copied over, and the build fails saying it cannot find libjpipe.jnilib. If I forcibly link it, I can continue the build, but then I get: ** ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/ca_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca/OpenOffice.app/Contents/program/unopkg sync --verbose - env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed! in function: register_extensions ** in function: register_extensionsstopping log at Tue Jul 24 17:29:46 2018 .. removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/stripped/bg ... I've no idea what that means and what could be causing that... So my question is whether there is anyone around who has any ideas or clues on where to start...? Considering that macOS is one of our largest downloads, it would be nice to not have to drop it from AOO 4.2.0. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A 4.1.6 Release
No worries. I have my VMs ready to go. > On Jul 23, 2018, at 12:47 AM, Peter kovacs wrote: > > Fyi: To my frustration I failed yesterday to proceed. My next timeslot is on > Wednesday. I hope nothing will interfere. > > Am 21. Juli 2018 08:28:47 MESZ schrieb Peter Kovacs : >> I hope i have time on Sunday. I wanted to proceed last Sunday but >> failed on this. >> Currently my calendar is kind of full. Next possible opportunity is >> conning Wednesday. >> >> I am undecided if the 4.1.6 will be the last release. But after 4.1.6 I >> agree 4.2.0 beta should get priority. I can imagine that at least one >> maintenance release could be possible while we stabilize 4.2.0. In the >> beta phase. >> >> >> Am 19. Juli 2018 19:49:46 MESZ schrieb Matthias Seidel >> : >>> Back to the topic: >>> >>> If we want to release 4.1.6, we should start the process described >>> here: >>> https://cwiki.apache.org/confluence/display/OOOUSERS/How+to+Cook+a+Release >>> >>> That said, 4.1.6 should really be the last 4.1.x. (my opinion). We >> have >>> to get 4.2.0 releasable! >>> >>> Regards, >>> >>>Matthias >>> >>> >>> Am 04.07.2018 um 23:45 schrieb Marcus: Am 04.07.2018 um 22:46 schrieb Kay Schenk: > On Wed, Jul 4, 2018 at 1:00 PM, Marcus >> wrote: > >> Am 04.07.2018 um 08:23 schrieb Peter Kovacs: >> >>> I think Jim is referring to the gstreamer situation, where we >>> decided >>> that we skip CentOS6 more or less for 4.2.0.And one argument was, >>> if they >>> want something they should support us. This is not showing >>> sympathy >>> for a >>> small user group that uses very old software for 2 more years >>> until >>> they >>> have to move to CentOS 7. I personally think that the gstreamer >>> Topic can >>> be solved after we have released a beta version. Damjan and I >> have >>> pointed >>> out a lot of possible ways to deal with the issue. Just for now I >>> think we >>> have other problems then gstreamer in 4.2.0. I think it is my >>> fault >>> that I >>> put that argument so much in the front line, but that stuck for >>> me. >>> >>> In the last months we had a drop in activity. And more then one >>> topic >>> received not the attention it deserved. I would not conclude that >>> anyone >>> has stopped caring at this point in time. >>> >>> >>> Let us conclude for now: >>> 4.1.x is still in maintenance. And in my opinion we could think >> of >>> maintaining it until 2020 when CentOS6 drops out of maintenance. >>> Some >>> support from CentOS6 side would be nice. But we need to search >>> someone for >>> this. >>> I have that on my todo list, but did not manage to follow it up. >>> >> >> incl. gstreamer 0.1.0 that is now within the 4.1.x code. >> >> PS: >> CentOS 6 will be supported until Nov 2020; which means another >> ~2.5 >> years. >> >> 4.2.0 has I think 3 bugs we know about and that blocks a beta >>> release. >>> Current target for building with gstreamer is CentOS7. Building >>> without >>> gstreamer could be done on CentOS6. We should keep the code in >>> trunc CentOS >>> 6 compatible where ever we can for now. That will make it easy to >>> back port >>> patches to 4.1.x if we decide to maintain 4.1.x until EOL of >>> CentOS6. >>> >> >> In 4.2.0 we can still keep gstreamer 0.1.0 or update to something >> newer. >> To be honest, I don't care *about this special topic*. >> >> And it is only relevant on Linux, right? >> >> IMHO more relevant is the baseline: When we increase the CentOS >> version we >> also raise the sysreq for Linux kernel, glibc, etc. This has a >> much >> bigger >> impact for our users. > > You are absolutely correct about this, Marcus. Monitoring the >>> 32-bit > Linux > downloads might help here. It does seem like AOO could be moving >>> away > from > 32-bit for Linux and other operating systems. I don't know what > impact this > will have overall though. I don't remember exactly, does the gstreamer 0.1.0 vs. 1.0.0 discussion is also connected to the Linux 32-bit builds? If so, a solution could be indeed to drop the 32-bit builds. From SF.net >> stats I get the following (2018-01-01 until today). BTW: Very likely it's the used OS the download is started from. And not >>> the OS where OpenOffice should be installed on. OS% --- Windows86,1165 Macintosh 7,8424 Unknown 4,9012 Linux 1,0621 Android 0,0762 BSD 0,0011 Solaris 0,0006 But even then, I'm sure the most downloads from resp. for Linux will be for 64-bit. Has anybody more exact numbers - or an idea how to get them? Marcus
