You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openoffice.apache.org by Oliver-Rainer Wittmann <or...@googlemail.com> on 2013/06/05 12:04:48 UTC
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Hi Hans Zybura,
On 04.06.2013 19:26, Hans Zybura wrote:
> Hi, comments inline...
>
> Crosspost to the api mailing list for a reason.
>
> Regards, Hans Zybura
>
>> -----Original Message----- From: Oliver-Rainer Wittmann
>> [mailto:orwittmann@googlemail.com] Sent: Monday, June 03, 2013
>> 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]:
>> migration of AOO 3.4.x/OOo 3.x user profile data - help needed
>>
>> Hi,
>>
>> small wrap-up at the top: - nobody prefers to migrate extensions
>> from AOO 3.4.x resp. OOo 3.x
>
> A couple of month ago there was a heated dispute about introducing
> incompatible changes for extensions in the addons.xcu (for negligible
> benefit). One of the arguments meant to silence the critics was:
> Well, it's no problem because we have an update mechanism for
> extensions. I expressed doubts if the update mechanism would work.
> Now it turns out I was wrong. I shouldn't have worried about the
> update mechanism. Without migration, users will have to find and
> reinstall all of their extensions anyway "by hand".
>
May be I should have said:
"Until now, nobody prefers to migrate extensions from AOO 3.4.x resp.
OOo 3.x".
> The current update mechanism for extensions simply looks for a newer
> version of the extension by use of a link provided by the extension
> developer himself. We did that for our extension, but didn't have to
> make use of it until now.
>
> OO developers decided not to take into account compatibility issues
> caused by introducing incompatible changes in addons.xcu. OK, so we
> have to deal with it. To prevent any trouble for our customers, we
> could very likely have provided an automatic update, so that an end
> user wouldn't have noticed any problem at all after a successful
> migration.
>
> Now OO developers are about to make it impossible for extension
> developers to simply provide an automatic update before or after the
> migration to AOO 4.0. Without migrating extensions, there is no
> automatic update path anymore.
>
> Great user experience! Great experience for extension developers and
> support folks!
>
> I remember much talk about the "eco system of AOO" on this mailing
> list. Is this what the talk was about?
>
I tried to get involved certain people on this topic.
I had send my intial post to dev@o.a.o and users@o.a.o. Sorry, that I
did not include api@o.a.o as I assumed that extension developers are
looking at dev@o.a.o.
The intention of this thread was not to present facts regarding the
development. It is meant to show on what I would like to work on for AOO
4.0 regarding the migration of the user profile and to get feedback on
it. (BTW, I had already started a discussion thread in January 2013
regarding the migration of the user profile - see thread "[IMPORTANT,
DISCUSS]: no migration/use of former user profile with AOO 4.0".)
I used terms like "I would like to ...", "My current preference is ..."
and "I need support and help ..." - I am not presenting facts.
I explicitly ask for help for these tasks.
I got no response and no feedback from users@o.a.o. I was disappointed
about it, because it means that nobody from users@o.a.o seems to be
interested to help/support me. From dev@o.a.o I only got feedback about
the risks of a user profile migration and that nobody prefers a
migration of the extensions.
I have taken your feedback as not constructive criticsm. Your feedback
sounds like that I decided that extensions will not be migrated. That is
not the case.
Earlier in January I already started a similar discussion - see above
mentioned thread. Here, no strong preferences regarding the migration of
extensions were given.
In this thread I expressed my willingness to work on the migration of
the user profile (which also contains the user installed extensions),
otherwise nothing will be migrated as stated in January. As this is not
a one-person show I asked for help and support. The only feedback I got
was that a migration might be risky and no one has preference to migrate
extensions.
Then I got your feedback which more or less killed my motivation to work
on the migration of the user profile.
May be you are volunteering to support me as you seem to be interested
in a working migration of the user profile?
Best regards, (a disappointed) Oliver.
>>
>> more comments inline.
>>
>> On 02.06.2013 13:17, Andrea Pescetti wrote:
>>> On 29/05/2013 Oliver-Rainer Wittmann wrote:
>>>> On 28.05.2013 18:23, Rob Weir wrote:
>>>>> Do we need to worry about the "messy" profiles that occurred
>>>>> from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw
>>>>> spell checking breaking, missing dictionaries, and crashes.
>>>>> One of the nice things about a "clean start" with AOO 4.0 was
>>>>> that we avoid these kinds of problems.
>>>> From my point of view AOO 3.4.x users which had problems due to
>>>> a "messy" profile and had solved these problems, can migrate
>>>> their profile to AOO 4.0. AOO 3.4.x users which does not had
>>>> solved their problems are able to suppress the migration of
>>>> their existing profile - see the corresponding FirstStartWizard
>>>> page for the user profile
>> migration.
>>>
>>> I agree with Rob here that, since we had only a few widely
>>> reported bugs in OpenOffice 3.4.1 and one of them depended on the
>>> profile migration, we should be rather conservative.
>>>
>>> I agree it's better not to migrate extensions, since some of
>>> them might not work in OpenOffice 4 and their description.xml
>>> file in most cases will only state that they need "OpenOffice 3.0
>>> or later".
>>>
>>>> Yes, an easy reset of the user profile would be great.
>>>
>>> This would be a very welcome improvement. Maybe technically this
>>> could invalidate the current profile and ask the user to restart
>>> OpenOffice, which would start on a clean profile. This would
>>> offer a good user experience (not optimal, since the optimal one
>>> would be triggered by a reinstallation too), and the right moment
>>> for the cleanup would be just after the code that checks if
>>> FirstStartWizard must be run and just before the profile is
>>> loaded and locked (which means that the "invalidate" bit must be
>>> set in a way that does not require profile access but probably a
>>> simple filesystem access... OK, I'll stop here!).
>>>
>>>> Thus, I assume that the risk of a defect or a regression is low
>>>> when solving issue 122398 and 122397 for AOO 4.0, except the
>>>> issue which would be "copied" from a "messy" user profile.
>>>
>>> This is a case to consider. So I would suggest to set the
>>> default answer to "Don't migrate" for extra safety, especially if
>>> we don't have an easy profile reset mechanism in place.
>>
>> I agree. But it will cause translation effort - see screenshot of
>> FirstStartWizard migration page [1] String "...If you do not want
>> to reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark the
>> check box." will be change to "...If you do want to reuse settings
>> in %PRODUCTNAME %PRODUCTVERSION, mark the check box."
>>
>>>
>>>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a
>>>> compressed form (.zip file or .tar.gz file or ...) or let me
>>>> know, if you want to try my builds.
>>>
>>> If you had a build available, it would be easier for the QA
>>> volunteers to test.
>>>
>>
>> Yes, that would be the best.
>>
>> I will make the changes on trunk. Then the buildbot builds and the
>> snapshot builds can be tested. As all changes will contain the ID
>> of the corresponding issue in the submit summary, it will be easy
>> to revert these changes.
>>
>> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
>>
>>
>> Best regards, Oliver.
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/5/13 3:32 PM, Andreas Säger wrote:
> Am 05.06.2013 14:50, Jürgen Schmidt wrote:
>> On 6/5/13 2:00 PM, Andreas Säger wrote:
>>> If the developers obviously have no clue how to get things right, if
>>> even the project lead seems to be completely clueless about the way his
>>> product works ...
>>
>> The developers try to improve the program over time and fix design
>> issues in a major version.
>>
>> Which leader, Apache projects have no single leader. I am at least no
>> leader of this project, I am just one developer who try bring things
>> forward.
>>
>
> If your clunky mail system would work, you could see which one I mean.
and my comment apply to Rob as well, we have no leader here only active
community members. And he asked of course valid questions that are not
yet solved or answered because of many other things that needed to be
addressed as well.
Juergen
>
>>
>>>
>>>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: api-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
Am 05.06.2013 14:50, Jürgen Schmidt wrote:
> On 6/5/13 2:00 PM, Andreas Säger wrote:
>> If the developers obviously have no clue how to get things right, if
>> even the project lead seems to be completely clueless about the way his
>> product works ...
>
> The developers try to improve the program over time and fix design
> issues in a major version.
>
> Which leader, Apache projects have no single leader. I am at least no
> leader of this project, I am just one developer who try bring things
> forward.
>
If your clunky mail system would work, you could see which one I mean.
>
>>
>>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/5/13 2:00 PM, Andreas Säger wrote:
> If the developers obviously have no clue how to get things right, if
> even the project lead seems to be completely clueless about the way his
> product works ...
The developers try to improve the program over time and fix design
issues in a major version.
Which leader, Apache projects have no single leader. I am at least no
leader of this project, I am just one developer who try bring things
forward.
Juergen
>
>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>
> ... how could I contribute anything useful?
>
> I do not even understand my own extension anymore that I wrote 6 years
> ago. I do understand my own code but not the complicated XML
> configuration. The only thing I know for sure is that most of this
> extension used to run with any version from 1.4.x until 3.x.
>
> How could I test anything if I do not have any access to version 4? Am I
> supposed to compile it from source code or what?
>
> Sorry guys. I can happily do my work version 3.4.1 for the rest of my
> life. ODF seems to be a dead horse anyway so I'm not afraid of file
> format changes in the future.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: api-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi Andreas,
On 05.06.2013 14:00, Andreas Säger wrote:
> If the developers obviously have no clue how to get things right, if
> even the project lead seems to be completely clueless about the way his
> product works ...
>
>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>
> ... how could I contribute anything useful?
- By giving constructive feedback
- By asking questions
- By helping with translation
- By helping with testing
- By helping with documentation
- By helping with marketing and promotion
- By setting up a test environment, installing old version OOo 3.x or
AOO 3.4.x, upgrading to AOO 4.0 and reporting success or failure
- By taking responsibility for certain management tasks
- ...
>
> I do not even understand my own extension anymore that I wrote 6 years
> ago. I do understand my own code but not the complicated XML
> configuration. The only thing I know for sure is that most of this
> extension used to run with any version from 1.4.x until 3.x.
>
> How could I test anything if I do not have any access to version 4? Am I
> supposed to compile it from source code or what?
By taking the stuff the community is providing - build bot results and
developer snapshots. These are installation sets that anybody of the
community can install easily.
Building it from source is also a good option.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
Am 10.06.2013 21:24, Andreas Säger wrote:
> Am 05.06.2013 14:31, Regina Henschel wrote:
>> Find a previous snapshot at
>> http://ci.apache.org/projects/openoffice/install/ under winsnap or linsnap.
>>
>> Kind regards
>> Regina
>>
>
> Apache_OpenOffice_4.0.0_Linux_x86-64_install-deb_en-US.tar.gz fails to
> install while destroying my existing AOO 3.4.1
> Same problem with
> Apache_OpenOffice_4.0.0_Linux_x86-64_install-deb_en-US.tar.gz_2013-06-10_04:12:05_1491332.tar.gz
>
Solution:
http://forum.openoffice.org/en/forum/viewtopic.php?f=74&t=50119
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
Am 05.06.2013 14:31, Regina Henschel wrote:
> Find a previous snapshot at
> http://ci.apache.org/projects/openoffice/install/ under winsnap or linsnap.
>
> Kind regards
> Regina
>
Apache_OpenOffice_4.0.0_Linux_x86-64_install-deb_en-US.tar.gz fails to
install while destroying my existing AOO 3.4.1
Same problem with
Apache_OpenOffice_4.0.0_Linux_x86-64_install-deb_en-US.tar.gz_2013-06-10_04:12:05_1491332.tar.gz
> sudo dpkg -i *.deb
> [sudo] password for andreas:
> Vormals nicht ausgewähltes Paket openoffice wird gewählt.
> dpkg: Entfernen von openoffice.org3 zugunsten von openoffice wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von openoffice.org3 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3-impress hängt von openoffice.org3 ab
> openoffice.org3 soll entfernt werden.
> dpkg: Betreffend openoffice_4.0.0-2_amd64.deb, welches openoffice enthält:
> openoffice kollidiert mit openoffice.org3
> openoffice.org3 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-base wird gewählt.
> dpkg: Entfernen von ooobasis3.4-base zugunsten von openoffice-base wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-base nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3-base hängt von ooobasis3.4-base ab
> ooobasis3.4-base soll entfernt werden.
> dpkg: Betreffend openoffice-base_4.0.0-2_amd64.deb, welches openoffice-base enthält:
> openoffice-base kollidiert mit ooobasis3.4-base
> ooobasis3.4-base (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-base_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-base wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-brand-base wird gewählt.
> dpkg: Entfernen von openoffice.org3-base zugunsten von openoffice-brand-base wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-base wird zugunsten von openoffice-brand-base entfernt.
> (Lese Datenbank ... 323621 Dateien und Verzeichnisse sind derzeit installiert.)
> Entpacken von openoffice-brand-base (aus openoffice-brand-base_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-calc wird gewählt.
> dpkg: Entfernen von openoffice.org3-calc zugunsten von openoffice-brand-calc wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-calc wird zugunsten von openoffice-brand-calc entfernt.
> Entpacken von openoffice-brand-calc (aus openoffice-brand-calc_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-draw wird gewählt.
> dpkg: Entfernen von openoffice.org3-draw zugunsten von openoffice-brand-draw wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-draw wird zugunsten von openoffice-brand-draw entfernt.
> Entpacken von openoffice-brand-draw (aus openoffice-brand-draw_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-en-us wird gewählt.
> Entpacken von openoffice-brand-en-us (aus openoffice-brand-en-us_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-impress wird gewählt.
> dpkg: Entfernen von openoffice.org3-impress zugunsten von openoffice-brand-impress wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-impress wird zugunsten von openoffice-brand-impress entfernt.
> Entpacken von openoffice-brand-impress (aus openoffice-brand-impress_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-math wird gewählt.
> dpkg: Entfernen von openoffice.org3-math zugunsten von openoffice-brand-math wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-math wird zugunsten von openoffice-brand-math entfernt.
> Entpacken von openoffice-brand-math (aus openoffice-brand-math_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-writer wird gewählt.
> dpkg: Entfernen von openoffice.org3-writer zugunsten von openoffice-brand-writer wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-writer wird zugunsten von openoffice-brand-writer entfernt.
> Entpacken von openoffice-brand-writer (aus openoffice-brand-writer_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-calc wird gewählt.
> dpkg: Entfernen von ooobasis3.4-calc zugunsten von openoffice-calc wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-calc wird zugunsten von openoffice-calc entfernt.
> Entpacken von openoffice-calc (aus openoffice-calc_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-core01 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core01 zugunsten von openoffice-core01 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core01 nicht möglich (--auto-deconfigure wird helfen):
> ooobasis3.4-gnome-integration hängt von ooobasis3.4-core01 ab
> ooobasis3.4-core01 soll entfernt werden.
> dpkg: Betreffend openoffice-core01_4.0.0-2_amd64.deb, welches openoffice-core01 enthält:
> openoffice-core01 kollidiert mit ooobasis3.4-core01
> ooobasis3.4-core01 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core01_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core01 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core02 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core02 zugunsten von openoffice-core02 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core02 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core02 ab
> ooobasis3.4-core02 soll entfernt werden.
> dpkg: Betreffend openoffice-core02_4.0.0-2_amd64.deb, welches openoffice-core02 enthält:
> openoffice-core02 kollidiert mit ooobasis3.4-core02
> ooobasis3.4-core02 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core02_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core02 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core03 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core03 zugunsten von openoffice-core03 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core03 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core03 ab
> ooobasis3.4-core03 soll entfernt werden.
> dpkg: Betreffend openoffice-core03_4.0.0-2_amd64.deb, welches openoffice-core03 enthält:
> openoffice-core03 kollidiert mit ooobasis3.4-core03
> ooobasis3.4-core03 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core03_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core03 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core04 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core04 zugunsten von openoffice-core04 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core04 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core04 ab
> ooobasis3.4-core04 soll entfernt werden.
> dpkg: Betreffend openoffice-core04_4.0.0-2_amd64.deb, welches openoffice-core04 enthält:
> openoffice-core04 kollidiert mit ooobasis3.4-core04
> ooobasis3.4-core04 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core04_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core04 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core05 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core05 zugunsten von openoffice-core05 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core05 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core05 ab
> ooobasis3.4-core05 soll entfernt werden.
> dpkg: Betreffend openoffice-core05_4.0.0-2_amd64.deb, welches openoffice-core05 enthält:
> openoffice-core05 kollidiert mit ooobasis3.4-core05
> ooobasis3.4-core05 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core05_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core05 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core06 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core06 zugunsten von openoffice-core06 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core06 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core06 ab
> ooobasis3.4-core06 soll entfernt werden.
> dpkg: Betreffend openoffice-core06_4.0.0-2_amd64.deb, welches openoffice-core06 enthält:
> openoffice-core06 kollidiert mit ooobasis3.4-core06
> ooobasis3.4-core06 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core06_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core06 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core07 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core07 zugunsten von openoffice-core07 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core07 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core07 ab
> ooobasis3.4-core07 soll entfernt werden.
> dpkg: Betreffend openoffice-core07_4.0.0-2_amd64.deb, welches openoffice-core07 enthält:
> openoffice-core07 kollidiert mit ooobasis3.4-core07
> ooobasis3.4-core07 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core07_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core07 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-draw wird gewählt.
> dpkg: Entfernen von ooobasis3.4-draw zugunsten von openoffice-draw wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-draw wird zugunsten von openoffice-draw entfernt.
> Entpacken von openoffice-draw (aus openoffice-draw_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us wird gewählt.
> Entpacken von openoffice-en-us (aus openoffice-en-us_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-base wird gewählt.
> Entpacken von openoffice-en-us-base (aus openoffice-en-us-base_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-calc wird gewählt.
> Entpacken von openoffice-en-us-calc (aus openoffice-en-us-calc_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-draw wird gewählt.
> Entpacken von openoffice-en-us-draw (aus openoffice-en-us-draw_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-help wird gewählt.
> Entpacken von openoffice-en-us-help (aus openoffice-en-us-help_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-impress wird gewählt.
> Entpacken von openoffice-en-us-impress (aus openoffice-en-us-impress_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-math wird gewählt.
> Entpacken von openoffice-en-us-math (aus openoffice-en-us-math_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-res wird gewählt.
> Entpacken von openoffice-en-us-res (aus openoffice-en-us-res_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-writer wird gewählt.
> Entpacken von openoffice-en-us-writer (aus openoffice-en-us-writer_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-gnome-integration wird gewählt.
> dpkg: Entfernen von ooobasis3.4-gnome-integration zugunsten von openoffice-gnome-integration wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-gnome-integration wird zugunsten von openoffice-gnome-integration entfernt.
> Entpacken von openoffice-gnome-integration (aus openoffice-gnome-integration_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-graphicfilter wird gewählt.
> dpkg: Entfernen von ooobasis3.4-graphicfilter zugunsten von openoffice-graphicfilter wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-graphicfilter wird zugunsten von openoffice-graphicfilter entfernt.
> Entpacken von openoffice-graphicfilter (aus openoffice-graphicfilter_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-images wird gewählt.
> dpkg: Entfernen von ooobasis3.4-images zugunsten von openoffice-images wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-images nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-images ab
> ooobasis3.4-images soll entfernt werden.
> dpkg: Betreffend openoffice-images_4.0.0-2_amd64.deb, welches openoffice-images enthält:
> openoffice-images kollidiert mit ooobasis3.4-images
> ooobasis3.4-images (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-images_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-images wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-impress wird gewählt.
> dpkg: Entfernen von ooobasis3.4-impress zugunsten von openoffice-impress wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-impress nicht möglich (--auto-deconfigure wird helfen):
> ooobasis3.4-ogltrans hängt von ooobasis3.4-impress ab
> ooobasis3.4-impress soll entfernt werden.
> dpkg: Betreffend openoffice-impress_4.0.0-2_amd64.deb, welches openoffice-impress enthält:
> openoffice-impress kollidiert mit ooobasis3.4-impress
> ooobasis3.4-impress (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-impress_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-impress wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-javafilter wird gewählt.
> dpkg: Entfernen von ooobasis3.4-javafilter zugunsten von openoffice-javafilter wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-javafilter wird zugunsten von openoffice-javafilter entfernt.
> Entpacken von openoffice-javafilter (aus openoffice-javafilter_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-math wird gewählt.
> dpkg: Entfernen von ooobasis3.4-math zugunsten von openoffice-math wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-math wird zugunsten von openoffice-math entfernt.
> Entpacken von openoffice-math (aus openoffice-math_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-ogltrans wird gewählt.
> dpkg: Entfernen von ooobasis3.4-ogltrans zugunsten von openoffice-ogltrans wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-ogltrans wird zugunsten von openoffice-ogltrans entfernt.
> Entpacken von openoffice-ogltrans (aus openoffice-ogltrans_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-onlineupdate wird gewählt.
> dpkg: Entfernen von ooobasis3.4-onlineupdate zugunsten von openoffice-onlineupdate wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-onlineupdate wird zugunsten von openoffice-onlineupdate entfernt.
> Entpacken von openoffice-onlineupdate (aus openoffice-onlineupdate_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-ooofonts wird gewählt.
> dpkg: Entfernen von ooobasis3.4-ooofonts zugunsten von openoffice-ooofonts wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-ooofonts wird zugunsten von openoffice-ooofonts entfernt.
> Entpacken von openoffice-ooofonts (aus openoffice-ooofonts_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-ooolinguistic wird gewählt.
> dpkg: Entfernen von ooobasis3.4-ooolinguistic zugunsten von openoffice-ooolinguistic wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-ooolinguistic wird zugunsten von openoffice-ooolinguistic entfernt.
> Entpacken von openoffice-ooolinguistic (aus openoffice-ooolinguistic_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-pyuno wird gewählt.
> dpkg: Entfernen von ooobasis3.4-pyuno zugunsten von openoffice-pyuno wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-pyuno wird zugunsten von openoffice-pyuno entfernt.
> Entpacken von openoffice-pyuno (aus openoffice-pyuno_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-ure wird gewählt.
> dpkg: Entfernen von openoffice.org-ure zugunsten von openoffice-ure wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von openoffice.org-ure nicht möglich (--auto-deconfigure wird helfen):
> ooobasis3.4-core01 hängt von openoffice.org-ure ab
> openoffice.org-ure soll entfernt werden.
> dpkg: Betreffend openoffice-ure_4.0.0-2_amd64.deb, welches openoffice-ure enthält:
> openoffice-ure kollidiert mit openoffice.org-ure
> openoffice.org-ure (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-ure_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-ure wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-writer wird gewählt.
> dpkg: Entfernen von ooobasis3.4-writer zugunsten von openoffice-writer wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-writer wird zugunsten von openoffice-writer entfernt.
> Entpacken von openoffice-writer (aus openoffice-writer_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-xsltfilter wird gewählt.
> dpkg: Entfernen von ooobasis3.4-xsltfilter zugunsten von openoffice-xsltfilter wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-xsltfilter wird zugunsten von openoffice-xsltfilter entfernt.
> Entpacken von openoffice-xsltfilter (aus openoffice-xsltfilter_4.0.0-2_amd64.deb) ...
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-base:
> openoffice-brand-base hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> openoffice-brand-base hängt ab von openoffice-base; aber:
> Paket openoffice-base ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-base (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-calc:
> openoffice-brand-calc hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-calc (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-draw:
> openoffice-brand-draw hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-draw (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-en-us:
> openoffice-brand-en-us hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-en-us (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-impress:
> openoffice-brand-impress hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> openoffice-brand-impress hängt ab von openoffice-impress; aber:
> Paket openoffice-impress ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-impress (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-math:
> openoffice-brand-math hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-math (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-writer:
> openoffice-brand-writer hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-writer (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-calc:
> openoffice-calc hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-calc (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-draw:
> openoffice-draw hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-draw (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us:
> openoffice-en-us hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-base:
> openoffice-en-us-base hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-base (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-calc:
> openoffice-en-us-calc hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-calc (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-draw:
> openoffice-en-us-draw hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-draw (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-help:
> openoffice-en-us-help hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-help (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-impress:
> openoffice-en-us-impress hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-impress (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-math:
> openoffice-en-us-math hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-math (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-res:
> openoffice-en-us-res hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-res (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-writer:
> openoffice-en-us-writer hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-writer (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-gnome-integration:
> openoffice-gnome-integration hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-gnome-integration (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-graphicfilter:
> openoffice-graphicfilter hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-graphicfilter (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-javafilter:
> openoffice-javafilter hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-javafilter (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-math:
> openoffice-math hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-math (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-ogltrans:
> openoffice-ogltrans hängt ab von openoffice-impress; aber:
> Paket openoffice-impress ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-ogltrans (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-onlineupdate:
> openoffice-onlineupdate hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-onlineupdate (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-ooofonts:
> openoffice-ooofonts hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-ooofonts (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-ooolinguistic:
> openoffice-ooolinguistic hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-ooolinguistic (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-pyuno:
> openoffice-pyuno hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-pyuno (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-writer:
> openoffice-writer hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-writer (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-xsltfilter:
> openoffice-xsltfilter hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-xsltfilter (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> Trigger für menu werden verarbeitet ...
> Fehler traten auf beim Bearbeiten von:
> openoffice_4.0.0-2_amd64.deb
> openoffice-base_4.0.0-2_amd64.deb
> openoffice-core01_4.0.0-2_amd64.deb
> openoffice-core02_4.0.0-2_amd64.deb
> openoffice-core03_4.0.0-2_amd64.deb
> openoffice-core04_4.0.0-2_amd64.deb
> openoffice-core05_4.0.0-2_amd64.deb
> openoffice-core06_4.0.0-2_amd64.deb
> openoffice-core07_4.0.0-2_amd64.deb
> openoffice-images_4.0.0-2_amd64.deb
> openoffice-impress_4.0.0-2_amd64.deb
> openoffice-ure_4.0.0-2_amd64.deb
> openoffice-brand-base
> openoffice-brand-calc
> openoffice-brand-draw
> openoffice-brand-en-us
> openoffice-brand-impress
> openoffice-brand-math
> openoffice-brand-writer
> openoffice-calc
> openoffice-draw
> openoffice-en-us
> openoffice-en-us-base
> openoffice-en-us-calc
> openoffice-en-us-draw
> openoffice-en-us-help
> openoffice-en-us-impress
> openoffice-en-us-math
> openoffice-en-us-res
> openoffice-en-us-writer
> openoffice-gnome-integration
> openoffice-graphicfilter
> openoffice-javafilter
> openoffice-math
> openoffice-ogltrans
> openoffice-onlineupdate
> openoffice-ooofonts
> openoffice-ooolinguistic
> openoffice-pyuno
> openoffice-writer
> openoffice-xsltfilter
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
Am 05.06.2013 14:31, Regina Henschel wrote:
> Hi Andreas,
> Find current snapshot on
> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
>
>
> It is not yet totally filled, because building is ongoing.
>
> Find a previous snapshot at
> http://ci.apache.org/projects/openoffice/install/ under winsnap or linsnap.
>
> Kind regards
> Regina
>
Thank you very much. That place is very well hidden from the public.
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Regina Henschel <rb...@t-online.de>.
Hi Andreas,
Andreas Säger schrieb:
> If the developers obviously have no clue how to get things right, if
> even the project lead seems to be completely clueless about the way his
> product works ...
>
>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>
> ... how could I contribute anything useful?
>
> I do not even understand my own extension anymore that I wrote 6 years
> ago. I do understand my own code but not the complicated XML
> configuration. The only thing I know for sure is that most of this
> extension used to run with any version from 1.4.x until 3.x.
>
> How could I test anything if I do not have any access to version 4? Am I
> supposed to compile it from source code or what?
Find current snapshot on
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
It is not yet totally filled, because building is ongoing.
Find a previous snapshot at
http://ci.apache.org/projects/openoffice/install/ under winsnap or linsnap.
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
If the developers obviously have no clue how to get things right, if
even the project lead seems to be completely clueless about the way his
product works ...
> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
... how could I contribute anything useful?
I do not even understand my own extension anymore that I wrote 6 years
ago. I do understand my own code but not the complicated XML
configuration. The only thing I know for sure is that most of this
extension used to run with any version from 1.4.x until 3.x.
How could I test anything if I do not have any access to version 4? Am I
supposed to compile it from source code or what?
Sorry guys. I can happily do my work version 3.4.1 for the rest of my
life. ODF seems to be a dead horse anyway so I'm not afraid of file
format changes in the future.
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Posted by Hans Zybura <hz...@zybura.com>.
Hi,
I'm sorry, I don't have the time to follow every post on the dev and api mailings lists. Being an add-in and extension developer for Microsoft Office and OpenOffice and having a well working add-in/extension for both in place, I normally only need to scan the lists once a week or so for relevant topics. The whole of my AOO extension activities, including support for users of our extension based product, is planned to take about 3% of my working time, in accordance to how much said extension contributes to my sales numbers and income. That's how my working life is organized.
When I happen to read this:
> >> small wrap-up at the top: - nobody prefers to migrate extensions from
> >> AOO 3.4.x resp. OOo 3.x
in conjunction with the obviously outdated and rather crude information about release planning here:
https://cwiki.apache.org/OOOUSERS/aoo-40-release-planning.html
it seems totally clear to me that nothing can change your "nobody prefers to migrate extensions" in time.
I will be delighted if I'm proved to be wrong, in which case I will gladly test the migration of our extension, and - if needed - open a bug report on bugzilla and help with resolving issues.
You know, from my point of view, the whole thread, starting only 5 days *after* the proposed date of RC1, left me speechless for a while, when I detected it. It had never occurred to me that in a project of this dimension one could even think about a new major release without careful and timely consideration of migration processes. The way this is handled looks very much like chaos to me, and I tend to no longer trust in AOO to be a serious, long-term, and reliable project. If this really is the Apache way of project management, it is nothing I want to get used to.
As a side note: my Windows and MacOS users don't "migrate", they wouldn't understand this geeky word. They are able to install a new software version, which is sort of a nuisance in itself for most of them. Afterwards, they expect to see everything in place like before. For most of the programs I use, I'm just such an end user myself. I expect those programs to install/update and then look and feel mostly like before or maybe a bit better, if I'm lucky. The last thing I want to be *told* is what I have to *do* for a proper "migration".
I realize that my stern remarks go partly to the wrong person. For this I apologize.
Regards, Hans
> From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
> Sent: Wednesday, June 05, 2013 12:05 PM
> Hi Hans Zybura,
>
> On 04.06.2013 19:26, Hans Zybura wrote:
> > Hi, comments inline...
> >
> > Crosspost to the api mailing list for a reason.
> >
> > Regards, Hans Zybura
> >
> >> -----Original Message----- From: Oliver-Rainer Wittmann
> >> [mailto:orwittmann@googlemail.com] Sent: Monday, June 03, 2013
> >> 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]:
> >> migration of AOO 3.4.x/OOo 3.x user profile data - help needed
> >>
> >> Hi,
> >>
> >
> > A couple of month ago there was a heated dispute about introducing
> > incompatible changes for extensions in the addons.xcu (for negligible
> > benefit). One of the arguments meant to silence the critics was:
> > Well, it's no problem because we have an update mechanism for
> > extensions. I expressed doubts if the update mechanism would work.
> > Now it turns out I was wrong. I shouldn't have worried about the
> > update mechanism. Without migration, users will have to find and
> > reinstall all of their extensions anyway "by hand".
> >
>
> May be I should have said:
> "Until now, nobody prefers to migrate extensions from AOO 3.4.x resp.
> OOo 3.x".
>
> > The current update mechanism for extensions simply looks for a newer
> > version of the extension by use of a link provided by the extension
> > developer himself. We did that for our extension, but didn't have to
> > make use of it until now.
> >
> > OO developers decided not to take into account compatibility issues
> > caused by introducing incompatible changes in addons.xcu. OK, so we
> > have to deal with it. To prevent any trouble for our customers, we
> > could very likely have provided an automatic update, so that an end
> > user wouldn't have noticed any problem at all after a successful
> > migration.
> >
> > Now OO developers are about to make it impossible for extension
> > developers to simply provide an automatic update before or after the
> > migration to AOO 4.0. Without migrating extensions, there is no
> > automatic update path anymore.
> >
> > Great user experience! Great experience for extension developers and
> > support folks!
> >
> > I remember much talk about the "eco system of AOO" on this mailing
> > list. Is this what the talk was about?
> >
>
> I tried to get involved certain people on this topic.
> I had send my intial post to dev@o.a.o and users@o.a.o. Sorry, that I did not
> include api@o.a.o as I assumed that extension developers are looking at
> dev@o.a.o.
>
> The intention of this thread was not to present facts regarding the
> development. It is meant to show on what I would like to work on for AOO
> 4.0 regarding the migration of the user profile and to get feedback on it.
> (BTW, I had already started a discussion thread in January 2013 regarding the
> migration of the user profile - see thread "[IMPORTANT,
> DISCUSS]: no migration/use of former user profile with AOO 4.0".)
>
> I used terms like "I would like to ...", "My current preference is ..."
> and "I need support and help ..." - I am not presenting facts.
> I explicitly ask for help for these tasks.
> I got no response and no feedback from users@o.a.o. I was disappointed
> about it, because it means that nobody from users@o.a.o seems to be
> interested to help/support me. From dev@o.a.o I only got feedback about
> the risks of a user profile migration and that nobody prefers a migration of
> the extensions.
>
> I have taken your feedback as not constructive criticsm. Your feedback
> sounds like that I decided that extensions will not be migrated. That is not
> the case.
> Earlier in January I already started a similar discussion - see above mentioned
> thread. Here, no strong preferences regarding the migration of extensions
> were given.
> In this thread I expressed my willingness to work on the migration of the user
> profile (which also contains the user installed extensions), otherwise nothing
> will be migrated as stated in January. As this is not a one-person show I asked
> for help and support. The only feedback I got was that a migration might be
> risky and no one has preference to migrate extensions.
> Then I got your feedback which more or less killed my motivation to work on
> the migration of the user profile.
>
> May be you are volunteering to support me as you seem to be interested in
> a working migration of the user profile?
>
>
> Best regards, (a disappointed) Oliver.
>
>
> >>
> >> more comments inline.
> >>
> >> On 02.06.2013 13:17, Andrea Pescetti wrote:
> >>> On 29/05/2013 Oliver-Rainer Wittmann wrote:
> >>>> On 28.05.2013 18:23, Rob Weir wrote:
> >>>>> Do we need to worry about the "messy" profiles that occurred
> >>>>> from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw
> >>>>> spell checking breaking, missing dictionaries, and crashes.
> >>>>> One of the nice things about a "clean start" with AOO 4.0 was
> >>>>> that we avoid these kinds of problems.
> >>>> From my point of view AOO 3.4.x users which had problems due to
> >>>> a "messy" profile and had solved these problems, can migrate
> >>>> their profile to AOO 4.0. AOO 3.4.x users which does not had
> >>>> solved their problems are able to suppress the migration of
> >>>> their existing profile - see the corresponding FirstStartWizard
> >>>> page for the user profile
> >> migration.
> >>>
> >>> I agree with Rob here that, since we had only a few widely
> >>> reported bugs in OpenOffice 3.4.1 and one of them depended on the
> >>> profile migration, we should be rather conservative.
> >>>
> >>> I agree it's better not to migrate extensions, since some of
> >>> them might not work in OpenOffice 4 and their description.xml
> >>> file in most cases will only state that they need "OpenOffice 3.0
> >>> or later".
> >>>
> >>>> Yes, an easy reset of the user profile would be great.
> >>>
> >>> This would be a very welcome improvement. Maybe technically this
> >>> could invalidate the current profile and ask the user to restart
> >>> OpenOffice, which would start on a clean profile. This would
> >>> offer a good user experience (not optimal, since the optimal one
> >>> would be triggered by a reinstallation too), and the right moment
> >>> for the cleanup would be just after the code that checks if
> >>> FirstStartWizard must be run and just before the profile is
> >>> loaded and locked (which means that the "invalidate" bit must be
> >>> set in a way that does not require profile access but probably a
> >>> simple filesystem access... OK, I'll stop here!).
> >>>
> >>>> Thus, I assume that the risk of a defect or a regression is low
> >>>> when solving issue 122398 and 122397 for AOO 4.0, except the
> >>>> issue which would be "copied" from a "messy" user profile.
> >>>
> >>> This is a case to consider. So I would suggest to set the
> >>> default answer to "Don't migrate" for extra safety, especially if
> >>> we don't have an easy profile reset mechanism in place.
> >>
> >> I agree. But it will cause translation effort - see screenshot of
> >> FirstStartWizard migration page [1] String "...If you do not want
> >> to reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark
> the
> >> check box." will be change to "...If you do want to reuse settings
> >> in %PRODUCTNAME %PRODUCTVERSION, mark the check box."
> >>
> >>>
> >>>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a
> >>>> compressed form (.zip file or .tar.gz file or ...) or let me
> >>>> know, if you want to try my builds.
> >>>
> >>> If you had a build available, it would be easier for the QA
> >>> volunteers to test.
> >>>
> >>
> >> Yes, that would be the best.
> >>
> >> I will make the changes on trunk. Then the buildbot builds and the
> >> snapshot builds can be tested. As all changes will contain the ID
> >> of the corresponding issue in the submit summary, it will be easy
> >> to revert these changes.
> >>
> >> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
> >>
> >>
> >> Best regards, Oliver.
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: api-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Posted by Hans Zybura <hz...@zybura.com>.
Hi,
I'm sorry, I don't have the time to follow every post on the dev and api mailings lists. Being an add-in and extension developer for Microsoft Office and OpenOffice and having a well working add-in/extension for both in place, I normally only need to scan the lists once a week or so for relevant topics. The whole of my AOO extension activities, including support for users of our extension based product, is planned to take about 3% of my working time, in accordance to how much said extension contributes to my sales numbers and income. That's how my working life is organized.
When I happen to read this:
> >> small wrap-up at the top: - nobody prefers to migrate extensions from
> >> AOO 3.4.x resp. OOo 3.x
in conjunction with the obviously outdated and rather crude information about release planning here:
https://cwiki.apache.org/OOOUSERS/aoo-40-release-planning.html
it seems totally clear to me that nothing can change your "nobody prefers to migrate extensions" in time.
I will be delighted if I'm proved to be wrong, in which case I will gladly test the migration of our extension, and - if needed - open a bug report on bugzilla and help with resolving issues.
You know, from my point of view, the whole thread, starting only 5 days *after* the proposed date of RC1, left me speechless for a while, when I detected it. It had never occurred to me that in a project of this dimension one could even think about a new major release without careful and timely consideration of migration processes. The way this is handled looks very much like chaos to me, and I tend to no longer trust in AOO to be a serious, long-term, and reliable project. If this really is the Apache way of project management, it is nothing I want to get used to.
As a side note: my Windows and MacOS users don't "migrate", they wouldn't understand this geeky word. They are able to install a new software version, which is sort of a nuisance in itself for most of them. Afterwards, they expect to see everything in place like before. For most of the programs I use, I'm just such an end user myself. I expect those programs to install/update and then look and feel mostly like before or maybe a bit better, if I'm lucky. The last thing I want to be *told* is what I have to *do* for a proper "migration".
I realize that my stern remarks go partly to the wrong person. For this I apologize.
Regards, Hans
> From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
> Sent: Wednesday, June 05, 2013 12:05 PM
> Hi Hans Zybura,
>
> On 04.06.2013 19:26, Hans Zybura wrote:
> > Hi, comments inline...
> >
> > Crosspost to the api mailing list for a reason.
> >
> > Regards, Hans Zybura
> >
> >> -----Original Message----- From: Oliver-Rainer Wittmann
> >> [mailto:orwittmann@googlemail.com] Sent: Monday, June 03, 2013
> >> 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]:
> >> migration of AOO 3.4.x/OOo 3.x user profile data - help needed
> >>
> >> Hi,
> >>
> >
> > A couple of month ago there was a heated dispute about introducing
> > incompatible changes for extensions in the addons.xcu (for negligible
> > benefit). One of the arguments meant to silence the critics was:
> > Well, it's no problem because we have an update mechanism for
> > extensions. I expressed doubts if the update mechanism would work.
> > Now it turns out I was wrong. I shouldn't have worried about the
> > update mechanism. Without migration, users will have to find and
> > reinstall all of their extensions anyway "by hand".
> >
>
> May be I should have said:
> "Until now, nobody prefers to migrate extensions from AOO 3.4.x resp.
> OOo 3.x".
>
> > The current update mechanism for extensions simply looks for a newer
> > version of the extension by use of a link provided by the extension
> > developer himself. We did that for our extension, but didn't have to
> > make use of it until now.
> >
> > OO developers decided not to take into account compatibility issues
> > caused by introducing incompatible changes in addons.xcu. OK, so we
> > have to deal with it. To prevent any trouble for our customers, we
> > could very likely have provided an automatic update, so that an end
> > user wouldn't have noticed any problem at all after a successful
> > migration.
> >
> > Now OO developers are about to make it impossible for extension
> > developers to simply provide an automatic update before or after the
> > migration to AOO 4.0. Without migrating extensions, there is no
> > automatic update path anymore.
> >
> > Great user experience! Great experience for extension developers and
> > support folks!
> >
> > I remember much talk about the "eco system of AOO" on this mailing
> > list. Is this what the talk was about?
> >
>
> I tried to get involved certain people on this topic.
> I had send my intial post to dev@o.a.o and users@o.a.o. Sorry, that I did not
> include api@o.a.o as I assumed that extension developers are looking at
> dev@o.a.o.
>
> The intention of this thread was not to present facts regarding the
> development. It is meant to show on what I would like to work on for AOO
> 4.0 regarding the migration of the user profile and to get feedback on it.
> (BTW, I had already started a discussion thread in January 2013 regarding the
> migration of the user profile - see thread "[IMPORTANT,
> DISCUSS]: no migration/use of former user profile with AOO 4.0".)
>
> I used terms like "I would like to ...", "My current preference is ..."
> and "I need support and help ..." - I am not presenting facts.
> I explicitly ask for help for these tasks.
> I got no response and no feedback from users@o.a.o. I was disappointed
> about it, because it means that nobody from users@o.a.o seems to be
> interested to help/support me. From dev@o.a.o I only got feedback about
> the risks of a user profile migration and that nobody prefers a migration of
> the extensions.
>
> I have taken your feedback as not constructive criticsm. Your feedback
> sounds like that I decided that extensions will not be migrated. That is not
> the case.
> Earlier in January I already started a similar discussion - see above mentioned
> thread. Here, no strong preferences regarding the migration of extensions
> were given.
> In this thread I expressed my willingness to work on the migration of the user
> profile (which also contains the user installed extensions), otherwise nothing
> will be migrated as stated in January. As this is not a one-person show I asked
> for help and support. The only feedback I got was that a migration might be
> risky and no one has preference to migrate extensions.
> Then I got your feedback which more or less killed my motivation to work on
> the migration of the user profile.
>
> May be you are volunteering to support me as you seem to be interested in
> a working migration of the user profile?
>
>
> Best regards, (a disappointed) Oliver.
>
>
> >>
> >> more comments inline.
> >>
> >> On 02.06.2013 13:17, Andrea Pescetti wrote:
> >>> On 29/05/2013 Oliver-Rainer Wittmann wrote:
> >>>> On 28.05.2013 18:23, Rob Weir wrote:
> >>>>> Do we need to worry about the "messy" profiles that occurred
> >>>>> from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw
> >>>>> spell checking breaking, missing dictionaries, and crashes.
> >>>>> One of the nice things about a "clean start" with AOO 4.0 was
> >>>>> that we avoid these kinds of problems.
> >>>> From my point of view AOO 3.4.x users which had problems due to
> >>>> a "messy" profile and had solved these problems, can migrate
> >>>> their profile to AOO 4.0. AOO 3.4.x users which does not had
> >>>> solved their problems are able to suppress the migration of
> >>>> their existing profile - see the corresponding FirstStartWizard
> >>>> page for the user profile
> >> migration.
> >>>
> >>> I agree with Rob here that, since we had only a few widely
> >>> reported bugs in OpenOffice 3.4.1 and one of them depended on the
> >>> profile migration, we should be rather conservative.
> >>>
> >>> I agree it's better not to migrate extensions, since some of
> >>> them might not work in OpenOffice 4 and their description.xml
> >>> file in most cases will only state that they need "OpenOffice 3.0
> >>> or later".
> >>>
> >>>> Yes, an easy reset of the user profile would be great.
> >>>
> >>> This would be a very welcome improvement. Maybe technically this
> >>> could invalidate the current profile and ask the user to restart
> >>> OpenOffice, which would start on a clean profile. This would
> >>> offer a good user experience (not optimal, since the optimal one
> >>> would be triggered by a reinstallation too), and the right moment
> >>> for the cleanup would be just after the code that checks if
> >>> FirstStartWizard must be run and just before the profile is
> >>> loaded and locked (which means that the "invalidate" bit must be
> >>> set in a way that does not require profile access but probably a
> >>> simple filesystem access... OK, I'll stop here!).
> >>>
> >>>> Thus, I assume that the risk of a defect or a regression is low
> >>>> when solving issue 122398 and 122397 for AOO 4.0, except the
> >>>> issue which would be "copied" from a "messy" user profile.
> >>>
> >>> This is a case to consider. So I would suggest to set the
> >>> default answer to "Don't migrate" for extra safety, especially if
> >>> we don't have an easy profile reset mechanism in place.
> >>
> >> I agree. But it will cause translation effort - see screenshot of
> >> FirstStartWizard migration page [1] String "...If you do not want
> >> to reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark
> the
> >> check box." will be change to "...If you do want to reuse settings
> >> in %PRODUCTNAME %PRODUCTVERSION, mark the check box."
> >>
> >>>
> >>>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a
> >>>> compressed form (.zip file or .tar.gz file or ...) or let me
> >>>> know, if you want to try my builds.
> >>>
> >>> If you had a build available, it would be easier for the QA
> >>> volunteers to test.
> >>>
> >>
> >> Yes, that would be the best.
> >>
> >> I will make the changes on trunk. Then the buildbot builds and the
> >> snapshot builds can be tested. As all changes will contain the ID
> >> of the corresponding issue in the submit summary, it will be easy
> >> to revert these changes.
> >>
> >> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
> >>
> >>
> >> Best regards, Oliver.
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: api-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org