LibreOffice Install and Use Problems

[Xen]

Oliver Grawert schreef op 28-09-2016 13:29:

> beyond this how do you know the bug is not caused by a (possibly)
> patched libboost, a gtk patch mint applies, held back upgrades or some
> weird filesystem mangling the mint installer does ... there are
> millions of possibilities you can not take into account without deeply
> knowing what mint does. it doesnt matter if it is a packaging problem
> or not as long as there is a possibility of something non-standard in
> the system causing it. if the mint support can nail it down with
> evidence to be an ubuntu problem, then yes, there is no issue at all
> with filing it on launchpad.

Intuition ;-).

Any root-owned-based-issues are not going to be related to libraries or 
GTK-issues.

I cannot attest to held-back upgrades because the command line "apt" 
system functions as I am used to from Ubuntu and even though my system 
is configured to not install kernel upgrades (from their GUI) I just saw 
a new kernel being installed through apt.

The latest version of LibreOffice was installed on that system on 11th 
of July. That's the current version. The system was installed on June, 
28. As far as apt history tells me .. well it was caused by apt-upgrade, 
not synaptic, so it would have installed everything. It is a long list 
and I have no clue what updates would have been held back by the "safe" 
system.

But that covers the span of June 28 to July 11.

I consider it almost impossible that not upgrading the kernel since the 
ISO version of Sarah would have created any trouble. It was probably the 
first upgrade... the installer must have run the commands of june 28.  
apt-get --force-yes --yes upgrade,  apt-get --force-yes --yes 
dist-upgrade, and then a long list of specified package on the command 
line 4 minutes later. Anyway.

June 28 was ISO install. July 11 was internet upgrade.

How likely that LibreOffice would not have worked if only it had been 
upgraded?

+ dependencies.

Further the likelyhood of Linux Mint pushing broken packages and holding 
back upgrades in something as predominant as LibreOffice and no one 
noticing until 2½ months later someone noticing is just...

The problems the user indicated were of the file-ownership kind and 
before a repository issue or a synaptic issue.

On a fresh Sarah install libreoffice is installed by default.

So either this is an older installation (and this is not a bug in the 
LibreOffice package) (not even against current Mint) or the person had 
installed LibreOffice before and mangled things up prior. I doubt that, 
but who knows. It seems to be an out of date system but at least it is 
clear from this that the current Mint does not suffer any such thing.

So that strengthens my conclusion that neither Ubuntu (packages) nor 
Mint (system) is to blame and indeed the person should report to Mint 
forums or something of the kind but the idea that this is a present day 
problem in Mint and would be caused by present day Mint alterations to 
the Ubuntu base system (if anything) is just not the conclusion of 
greatest likelihood here. Sarah upgrades from older versions of Mint 
suffer frequent problems and in general is completely disregarded as a 
viable path; the entire dist-upgrade feature for Mint causes even many 
more problems than it has on Ubuntu.

For this reason I simply wonder what kind of system the user has; even 
though possible, it is doubtful it is a fresh install of Sarah?

Regardless, the quick assumption that it must be something to do with 
Mint an sich and its alterations just doesn't seem very viable.

The only reason I was writing this is that I can understand your point 
of view (Mint goes to Mint first, this is a user support question and 
has nothing to do straight away with ubuntu-devel-discuss) but also that 
of the OP (if it is a package issue, it is not unfair to report it 
against ubuntu).

 From my point of view it can be reconciled by saying:
- It is understandable to use the email address you see in the package; 
because where else can you turn to so rapidly, I don't think has a 
strong presence in direct (email) customer support, in that sense.
- It is understandable that as a user you could or would have no clue as 
to what is causing this issue.
- If it /were/ a proper package issue you would be welcome here but 
given everything we know this is just not likely.
- I'm sorry, but even if you fall into a support gap because of this 
your place is at Mint
- Perhaps the system needs better tools to directly query the experience 
of other people, such as being able to (automatically) report statistics 
on correct and incorrect installs, works for me doesn't work for me, 
etc.

Suppose we had a system of maybe 4 tiers of simple binary statements:

- installs / doesn't install
- runs / doesn't run (works / doesn't work)
- works well / doesn't work well (I can get it to work and it does as 
advertized)
- content / not content.

People never like giving information as a default operation, but only as 
a choice, I guess.

Regardless you could think of the first quality to be automatically 
determined.
The second quality could be a quick self-test of the package.
Only the 3rd and 4th are really user-choices.

They would be "functions for me" and "I like it".

Something like /installs/works/functions/like.

Then people could query the database on that package to see if there are 
any problems with it before they report it.

Ideally you have system information to go with it so it would be 
required to specify the source of the system in order to be able to use 
the system. It would be required to specify both distribution type/name 
(Ubuntu, derivate, Mint, something else) as well as state of the system 
(fresh install, upgrade from older version). It would just be a common 
task in a GUI system to process user-relevant packages. Libraries would 
be excluded and the user needs to choose to either automatically report 
them, report them as part of personal choice (each time) or not report 
them at all. Libraries then only report quality 1 and 2. Ideally you 
should be able to edit the list of what you report, because principally 
enough information is sent to identify your system (IP address). User 
programs that are relevant enough (such as those that require 
configuration (Samba, autofs) or meaningful to a user (as a recognisable 
entity you manually install) would be on the list of a task for the user 
to perform.

The GUI pops up a screen that is nothing but a vertical list with 
horizontally the 4 choices (and name of the package to the left). Or 
just two choices with the option to adjust the other two.

Crafting a PHP mockup in jQuery if you like (my GTK/Python knowledge is 
too abysmal at present).



> in general though i was reacting to:
> 
> "The last time I tried to report a bug in this package, someone told me
> I was in the wrong place. I am not sure how talking to the package
> maintainers could be the wrong place!"
> ...
> "Unless I am mistaken, you are the package maintainers, so it does not
> matter what Linux system it is installed on, it should work, right?"
> 
> it *does* matter a lot and the way the mint developers picked to create
> their distro plays a big role here.

Well yes but with the information we have we don't need to make a 
fundamental or principial or theoretical claim here, it is enough that 
you already know it is probably not an issue with the package and with 
the Mint system at all, so you don't even have etc come to the point 
where you have to make such fundamental statements such as would be the 
case if the problem were related to Mint or its deviations and you 
wouldn't be able to tell anymore what differences that would make. I'm 
just saying that is two steps further.

Step 1: user question or development question?
Step 2: recent system or something already broken?
Step 3: Mint or Debian or Ubuntu?

I understand that you would cut things short and save time; by answering 
step 3 and then throwing away steps 1 and 2 as irrelevant.

However the assumption that "surely it is a Mint issue" is unwarranted 
or "You can never know what alterations base Mint has made" and you can 
simply say: yes perhaps you would have been welcome here but today is 
not the day because we are answering step 1 and with the information we 
have it is extremely unlikely to be a package problem with Ubuntu; 
please report to Mint instead (and that should be enough).

Then you can also say: it is unlikely that Mint-wide this is going to be 
broken (but you don't really have to).

Then you can say: There are problems between Ubuntu and Mint and we 
can't guarantee operation of our packages, but unless you are working on 
a recent system and you are certain you are not the only one 
experiencing this and you are certain the Mint people haven't done 
anything strange or you can reproduce it on Ubuntu and you have 
consulted the Mint people we cannot do anything for you anyway because 
we would need Mint developer resources and we are not going to do that.

Basically I would say:

Step 1: differentiate between package issue and non-package issue
Step 2: differentiate between normal Mint and abnormal Mint
Step 3: differentiate between Mint and Debian and Ubuntu

It is enough that you say: we know of no problems with our package; we 
would have been told such things; it is unlikely your distribution would 
have distribution wide problems with the package; your distribution 
would have fixed it or told us; and furthermore we are not Mint and 
cannot solve Mint development problems.

If you follow through all of those steps you are welcome back.

When you are sure it is a development issue for Ubuntu.

It's just that the user has no way to find out this information quickly 
on his own and turns to the email address to find out, unfortunately 
(?).

But maybe it is fortunate if we get a better system as a result, I will 
go make my mockup :p.