ubuntu-phone team mailing list archive

[Sam Bull <sam.hacking@xxxxxxxx>]

OK, my laptop got destroyed, but has been fixed and I am back trying to
sort this out again.

This is the status at the moment:

    When launching the app, there are a couple of apparmor denials about
    trying to read /usr/local/lib/python3.4/dist-packages.
        This proves that it is atleast running the Python binary.

    We changed it to an unconfined app. This means there are no more
    denials, but it still does not launch, and there are still no logs,
    crash reports or files written anywhere.

    We then wanted to check the unconfined nature of the app, and so
    edited the desktop file and changed the Exec line to something like
    'touch /home/phablet/testfile'. Still, this did not actually succeed
    in writing a file.

    We then tried editing the filemanager-app's desktop file with the
    same command. This successfully wrote a file.

    So, now we are really confused as to how the filemanager-app is able
    to write this file, but our app is not able to. Despite running the
    same command, and according to Permy having the same apparmor rules.


On Mon, 2016-02-08 at 17:43 +0100, Niklas Wenzel wrote:
> It might be worth having a look at the unity8/unity8-dash logs.
> 
> Am Montag, 8. Februar 2016 schrieb Sam Bull :
> > On lun, 2016-02-08 at 14:30 +0000, Alan Pope wrote:
> >> Anything interesting in dmesg? Specifically any apparmor failures?
> >>   sudo dmesg | grep DEN
> >
> > OK, a few DENIED messages in dmesg, but still no log.
> >
> > The messages are things I don't think should stop the program from
> > running:
> >
> > open /usr/local/lib/python3.4/dist-packages: Not sure why it's
> hitting
> > here, I've set sys.path to only local directories.
> >
> > mknod [app_path]/lib/PyQt5/__pycache__/__init__.cpython
> -34.3076567890:
> > I'm not sure exactly what this is trying to do, but I imagine that
> it
> > wouldn't break a program.
> >
> > open /etc/default/apport
> > open /etc/apt/apt.conf.d/: I believe these are a Canonical thing,
> again,
> > I don't think they would cause a problem.
> >
> > This does prove that Python is running. But, without a stack trace
> from
> > Python, I'm not sure what is failing.
> >

Attachment: signature.asc
Description: This is a digitally signed message part