Re: User Installation Process Feedback
Hi All, I now have installed AOO on Ubuntu Unity 22.04 and the UI falls back to some kind of Windows look. I also have big problems when the windows size changes. Maybe we can circumvent these problems with an AppImage? If I only could test one... ;-) Regards, Matthias Am 12.06.23 um 23:09 schrieb Matthias Seidel: Hi Andrea, Any news on this? I would love to test the AppImage! Regards, Matthias Am 08.05.23 um 18:37 schrieb Andrea Pescetti: On 07/05/23 Dave Fisher wrote: For those just now looking into this here is a link: https://docs.appimage.org/ If we switch to this packaging it appears that we can significantly reduce the many Linux packages we create when we release. I've done a recent build to produce an AppImage a few weeks (ahem..) ago, but I missed the final packaging and did not have time for it. I can complete it and put it somewehere on home.apache.org next weekend if anyone wishes to play with it. It's basically the same as https://archive.fosdem.org/2022/schedule/event/openoffice_linux_packaging/ Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org smime.p7s Description: S/MIME Cryptographic Signature
Re: User Installation Process Feedback
Hi Andrea, Any news on this? I would love to test the AppImage! Regards, Matthias Am 08.05.23 um 18:37 schrieb Andrea Pescetti: > On 07/05/23 Dave Fisher wrote: >> For those just now looking into this here is a link: >> https://docs.appimage.org/ >> If we switch to this packaging it appears that we can significantly >> reduce the many Linux packages we create when we release. > > I've done a recent build to produce an AppImage a few weeks (ahem..) > ago, but I missed the final packaging and did not have time for it. > > I can complete it and put it somewehere on home.apache.org next > weekend if anyone wishes to play with it. > > It's basically the same as > https://archive.fosdem.org/2022/schedule/event/openoffice_linux_packaging/ > > Regards, > Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Fwd: Re: User Installation Process Feedback
Resending my email from yesterday :) -- Original Message -- From: Pedro Lino To: dev@openoffice.apache.org Date: 05/08/2023 6:32 PM WEST Subject: Re: User Installation Process Feedback Hi Andrea > On 05/08/2023 5:37 PM BST Andrea Pescetti mailto:pesce...@apache.org> wrote: > > > On 07/05/23 Dave Fisher wrote: > > > For those just now looking into this here is a link: > > https://docs.appimage.org/ > > If we switch to this packaging it appears that we can significantly reduce > > the many Linux packages we create when we release. > > > I've done a recent build to produce an AppImage a few weeks (ahem..) > ago, but I missed the final packaging and did not have time for it. > > I can complete it and put it somewehere on home.apache.org next weekend > if anyone wishes to play with it. > Yes, please! Is it 4.1.14? Thanks! Pedro > > It's basically the same as > https://archive.fosdem.org/2022/schedule/event/openoffice_linux_packaging/ > > Regards, > Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > mailto:dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > mailto:dev-h...@openoffice.apache.org >
Re: User Installation Process Feedback
Hi Andrea, Am 08.05.23 um 18:37 schrieb Andrea Pescetti: > On 07/05/23 Dave Fisher wrote: >> For those just now looking into this here is a link: >> https://docs.appimage.org/ >> If we switch to this packaging it appears that we can significantly >> reduce the many Linux packages we create when we release. > > I've done a recent build to produce an AppImage a few weeks (ahem..) > ago, but I missed the final packaging and did not have time for it. > > I can complete it and put it somewehere on home.apache.org next > weekend if anyone wishes to play with it. Yes, that would be great! Regards, Matthias > > It's basically the same as > https://archive.fosdem.org/2022/schedule/event/openoffice_linux_packaging/ > > Regards, > Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: User Installation Process Feedback
This was a system wide problem which is now resolved. Thanks to Infra! Matthias Am 09.05.23 um 13:10 schrieb Matthias Seidel: > Hi all, > > Yesterday, I answered to Andreas' post, but it still does not show up > here... > > Is it "lost in moderation" or do we have technical problems? > > Regards, > > Matthias > > Am 08.05.23 um 18:37 schrieb Andrea Pescetti: >> On 07/05/23 Dave Fisher wrote: >>> For those just now looking into this here is a link: >>> https://docs.appimage.org/ >>> If we switch to this packaging it appears that we can significantly >>> reduce the many Linux packages we create when we release. >> I've done a recent build to produce an AppImage a few weeks (ahem..) >> ago, but I missed the final packaging and did not have time for it. >> >> I can complete it and put it somewehere on home.apache.org next >> weekend if anyone wishes to play with it. >> >> It's basically the same as >> https://archive.fosdem.org/2022/schedule/event/openoffice_linux_packaging/ >> >> Regards, >> Andrea. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> smime.p7s Description: S/MIME Cryptographic Signature
Re: User Installation Process Feedback
Hi all, Yesterday, I answered to Andreas' post, but it still does not show up here... Is it "lost in moderation" or do we have technical problems? Regards, Matthias Am 08.05.23 um 18:37 schrieb Andrea Pescetti: > On 07/05/23 Dave Fisher wrote: >> For those just now looking into this here is a link: >> https://docs.appimage.org/ >> If we switch to this packaging it appears that we can significantly >> reduce the many Linux packages we create when we release. > > I've done a recent build to produce an AppImage a few weeks (ahem..) > ago, but I missed the final packaging and did not have time for it. > > I can complete it and put it somewehere on home.apache.org next > weekend if anyone wishes to play with it. > > It's basically the same as > https://archive.fosdem.org/2022/schedule/event/openoffice_linux_packaging/ > > Regards, > Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: User Installation Process Feedback
On 07/05/23 Dave Fisher wrote: For those just now looking into this here is a link: https://docs.appimage.org/ If we switch to this packaging it appears that we can significantly reduce the many Linux packages we create when we release. I've done a recent build to produce an AppImage a few weeks (ahem..) ago, but I missed the final packaging and did not have time for it. I can complete it and put it somewehere on home.apache.org next weekend if anyone wishes to play with it. It's basically the same as https://archive.fosdem.org/2022/schedule/event/openoffice_linux_packaging/ Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: User Installation Process Feedback
Hello Damjan, hello all the main problem for AOO to become part of a distribution is, that it isn't possible to build it along the distribution policy from source. I can say it especially for the Debian-based distributions. Kind regards Mechtilde Am 15.02.23 um 17:39 schrieb Damjan Jovanovic: On Wed, Feb 15, 2023 at 2:52 PM wrote: Hello GB Mac, Le 2023-02-15 06:36, GB Mac a écrit : OpenOffice remains a perpetual developer project in Linux. It's a problem to do with your Linux distribution (which you don't specify). See with them so that the DEB or RPM package is set online in their repositories. Both the technical and political reality of software installation on Linux, is that Linux distribution repositories never could have been, and never will be, the one and only source of software to install. Repositories legally cannot package commercial software for example, and as the (now obsolete) Autopackage project quite correctly noticed around 2005, and its founder Mike Hearn gave a talk about to Gentoo developers at some conference in those days, the Linux distributions' repository has a monopoly on easy software installation, which distributions use as a political weapon against software that they don't like, whether it isn't UNIX-y enough, or has a strange licence, or isn't popular enough, or they just don't like for some personal reason. And there is trouble in paradise even for packages that make it into a distro repository. Distributions often ship old versions, and update on an awkward schedule. Inkscape used to have a release schedule where new releases would come out shortly after Ubuntu releases. As a result they had to deal with endless duplicate bug reports, from Ubuntu users installing the old version, and reporting bugs that were already fixed, but with no easy way to install the new version. Eventually Inkscape changed its release schedule to allow Ubuntu to package its latest version, but you can see the problem with this: should tens of thousands of packages really be forced to release in lock-step with Ubuntu? So the problem of 3rd party software installation has plagued Linux since inception: I documented 8 projects that tried to achieve that and compared them in the attached spreadsheet, and there are more. In bug 46333 users wanted an Autopackage of OpenOffice. Luckily in recent years the Linux distributions seem to have finally woken up, and begun officially supporting installation of 3rd party software, Ubuntu with Snap, and Red Hat with Flatpak. LibreOffice already offers Snap, Flatpak and AppImage, although I've found them to be of poor quality. Flatpak can work on Ubuntu too. AppImage isn't sandboxed at all. Snap is a disaster and will probably fail like most Canonical technologies. I definitely think Flatpak is the way to go. However it will require some development. We don't (only) use the standard GTK file dialogs, which automatically go through a "Portal" to allow us out of the sandbox, so we have to use the Portal API to gain permission to read the selected document somehow. Regards Damjan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: User Installation Process Feedback
For those just now looking into this here is a link: https://docs.appimage.org/ If we switch to this packaging it appears that we can significantly reduce the many Linux packages we create when we release. Interesting. Best, Dave Sent from my iPhone > On May 7, 2023, at 9:39 AM, Matthias Seidel > wrote: > > Hi All, > > Any news on this topic? > > If we want it to happen we need to work on it... > > Regards, > >Matthias > >> Am 21.03.23 um 16:19 schrieb Matthias Seidel: >> Hi All, >> >> Now that AOO 4.1.14 is released wouldn't it be the perfect time to start >> development on an AppImage (or similar)? >> >> Regards, >> >>Matthias >> >>> Am 18.02.23 um 13:48 schrieb Matthias Seidel: >>> Hi, >>> >>> Am 15.02.23 um 18:05 schrieb Yury Tarasievich: On 15/02/2023 19:39, Damjan Jovanovic wrote: > I documented 8 projects that tried to achieve that and compared them > in the attached spreadsheet, and there are more. The document is a beaut, but you've excluded Flatpak and Snap, one of which you sort of condemn and one of which you recommend, nevertheless. Why not AppImage, for which half a work is already there, AFAIU ? (I mean `installed` method of packaging) So it hasn't got sandboxing. Is it such a big deal? >>> I don't think we need sandboxing in the first place. >>> >>> An easy to install package for Linux would be good, so maybe we can try >>> to do an Appimage package after the release of AOO 4.1.14? >>> >>> Regards, >>> >>>Matthias >>> Also, any new packaging method would have to integrate into the existing build framework? Which isn't exactly a model of clarity and robustness? -Yury - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org >
Re: User Installation Process Feedback
Hi All, Any news on this topic? If we want it to happen we need to work on it... Regards, Matthias Am 21.03.23 um 16:19 schrieb Matthias Seidel: > Hi All, > > Now that AOO 4.1.14 is released wouldn't it be the perfect time to start > development on an AppImage (or similar)? > > Regards, > > Matthias > > Am 18.02.23 um 13:48 schrieb Matthias Seidel: >> Hi, >> >> Am 15.02.23 um 18:05 schrieb Yury Tarasievich: >>> On 15/02/2023 19:39, Damjan Jovanovic wrote: >>> I documented 8 projects that tried to achieve that and compared them in the attached spreadsheet, and there are more. >>> The document is a beaut, but you've excluded Flatpak and Snap, one of >>> which you sort of condemn and one of which you recommend, nevertheless. >>> >>> Why not AppImage, for which half a work is already there, AFAIU ? (I >>> mean `installed` method of packaging) So it hasn't got sandboxing. Is >>> it such a big deal? >> I don't think we need sandboxing in the first place. >> >> An easy to install package for Linux would be good, so maybe we can try >> to do an Appimage package after the release of AOO 4.1.14? >> >> Regards, >> >> Matthias >> >>> Also, any new packaging method would have to integrate into the >>> existing build framework? Which isn't exactly a model of clarity and >>> robustness? >>> >>> -Yury >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> smime.p7s Description: S/MIME Cryptographic Signature
Re: User Installation Process Feedback
Hi All, Now that AOO 4.1.14 is released wouldn't it be the perfect time to start development on an AppImage (or similar)? Regards, Matthias Am 18.02.23 um 13:48 schrieb Matthias Seidel: > Hi, > > Am 15.02.23 um 18:05 schrieb Yury Tarasievich: >> On 15/02/2023 19:39, Damjan Jovanovic wrote: >> >>> I documented 8 projects that tried to achieve that and compared them >>> in the attached spreadsheet, and there are more. >> The document is a beaut, but you've excluded Flatpak and Snap, one of >> which you sort of condemn and one of which you recommend, nevertheless. >> >> Why not AppImage, for which half a work is already there, AFAIU ? (I >> mean `installed` method of packaging) So it hasn't got sandboxing. Is >> it such a big deal? > I don't think we need sandboxing in the first place. > > An easy to install package for Linux would be good, so maybe we can try > to do an Appimage package after the release of AOO 4.1.14? > > Regards, > > Matthias > >> Also, any new packaging method would have to integrate into the >> existing build framework? Which isn't exactly a model of clarity and >> robustness? >> >> -Yury >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> smime.p7s Description: S/MIME Cryptographic Signature
Re: User Installation Process Feedback
Hi, Am 15.02.23 um 18:05 schrieb Yury Tarasievich: > On 15/02/2023 19:39, Damjan Jovanovic wrote: > >> I documented 8 projects that tried to achieve that and compared them >> in the attached spreadsheet, and there are more. > > The document is a beaut, but you've excluded Flatpak and Snap, one of > which you sort of condemn and one of which you recommend, nevertheless. > > Why not AppImage, for which half a work is already there, AFAIU ? (I > mean `installed` method of packaging) So it hasn't got sandboxing. Is > it such a big deal? I don't think we need sandboxing in the first place. An easy to install package for Linux would be good, so maybe we can try to do an Appimage package after the release of AOO 4.1.14? Regards, Matthias > > Also, any new packaging method would have to integrate into the > existing build framework? Which isn't exactly a model of clarity and > robustness? > > -Yury > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: User Installation Process Feedback
On 15/02/2023 19:39, Damjan Jovanovic wrote: I documented 8 projects that tried to achieve that and compared them in the attached spreadsheet, and there are more. The document is a beaut, but you've excluded Flatpak and Snap, one of which you sort of condemn and one of which you recommend, nevertheless. Why not AppImage, for which half a work is already there, AFAIU ? (I mean `installed` method of packaging) So it hasn't got sandboxing. Is it such a big deal? Also, any new packaging method would have to integrate into the existing build framework? Which isn't exactly a model of clarity and robustness? -Yury - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: User Installation Process Feedback
On Wed, Feb 15, 2023 at 2:52 PM wrote: > Hello GB Mac, > > Le 2023-02-15 06:36, GB Mac a écrit : > > OpenOffice remains a perpetual > > developer project in Linux. > It's a problem to do with your Linux distribution (which you don't > specify). > See with them so that the DEB or RPM package is set online in their > repositories. > > Both the technical and political reality of software installation on Linux, is that Linux distribution repositories never could have been, and never will be, the one and only source of software to install. Repositories legally cannot package commercial software for example, and as the (now obsolete) Autopackage project quite correctly noticed around 2005, and its founder Mike Hearn gave a talk about to Gentoo developers at some conference in those days, the Linux distributions' repository has a monopoly on easy software installation, which distributions use as a political weapon against software that they don't like, whether it isn't UNIX-y enough, or has a strange licence, or isn't popular enough, or they just don't like for some personal reason. And there is trouble in paradise even for packages that make it into a distro repository. Distributions often ship old versions, and update on an awkward schedule. Inkscape used to have a release schedule where new releases would come out shortly after Ubuntu releases. As a result they had to deal with endless duplicate bug reports, from Ubuntu users installing the old version, and reporting bugs that were already fixed, but with no easy way to install the new version. Eventually Inkscape changed its release schedule to allow Ubuntu to package its latest version, but you can see the problem with this: should tens of thousands of packages really be forced to release in lock-step with Ubuntu? So the problem of 3rd party software installation has plagued Linux since inception: I documented 8 projects that tried to achieve that and compared them in the attached spreadsheet, and there are more. In bug 46333 users wanted an Autopackage of OpenOffice. Luckily in recent years the Linux distributions seem to have finally woken up, and begun officially supporting installation of 3rd party software, Ubuntu with Snap, and Red Hat with Flatpak. LibreOffice already offers Snap, Flatpak and AppImage, although I've found them to be of poor quality. Flatpak can work on Ubuntu too. AppImage isn't sandboxed at all. Snap is a disaster and will probably fail like most Canonical technologies. I definitely think Flatpak is the way to go. However it will require some development. We don't (only) use the standard GTK file dialogs, which automatically go through a "Portal" to allow us out of the sandbox, so we have to use the Portal API to gain permission to read the selected document somehow. Regards Damjan 3rd party software installation.ods Description: application/vnd.oasis.opendocument.spreadsheet - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: User Installation Process Feedback
Hi Graeme Thank you for the kind words. We do agree it is good to have an Open Source alternative. The installation is indeed not user friendly (requires to unpack and execute a command line instruction). Unfortunately we do not have a volunteer to implement an installer. This is something that would indeed increase the visibility of the program under Linux (although that is not the primary AOO user platform). Let's hope there is a volunteer who would like to scratch this itch ;) All the best, Pedro > On 02/15/2023 5:36 AM WET GB Mac wrote: > > > Hi, > > First I would like to thank everyone who makes OpenOffice available, it > is appreciated to have a LibreOffice alternative in the open source world. > > Second I would like to say the installation process is a large barrier > to general uptake of the software. The fact that there are no simple, single > file, ready to install package makes this a niche power user project as > opposed to something that is truly accessible to everyone. The software is > likely great, I used it back in my Windows days and it was nice to have, but > in Linux it's only a couple of notches simpler than building it from source > code.Yes, many of us could do it but most don't because it's a pain in > the butt and this ensures that LibreOffice wins and OpenOffice remains a > perpetual developer project in Linux. I'm writing this because I like > OpenOffice, I like Apache and it's unfortunate that it's as inaccessible as > it is. Please fix this and OpenOffice could actually become popular in > Linux if that's the goal. > > Thanks. > > -Grahame - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: User Installation Process Feedback
Hi all, It is not an easy step to get AOO (back) into a distribution... A better way would be to use alternative packaging formats: https://archive.fosdem.org/2022/schedule/event/openoffice_linux_packaging/ But, as always, it needs someone to do the work. This is a volunteers project, so every help is welcome! Regards, Matthias Am 15.02.23 um 13:51 schrieb club.a...@free.fr: > Hello GB Mac, > > Le 2023-02-15 06:36, GB Mac a écrit : >> OpenOffice remains a perpetual >> developer project in Linux. > It's a problem to do with your Linux distribution (which you don't > specify). > See with them so that the DEB or RPM package is set online in their > repositories. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: User Installation Process Feedback
Hello GB Mac, Le 2023-02-15 06:36, GB Mac a écrit : OpenOffice remains a perpetual developer project in Linux. It's a problem to do with your Linux distribution (which you don't specify). See with them so that the DEB or RPM package is set online in their repositories. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
